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CHAPTER  1 


GPS  Language 


1.1.  Introduction 

GPS  is  a  PostScript'  like  language  for  performing  steady-state  and  dynamic  system  simulations.  The  systems 
that  can  be  analyzed  consist  of  arbitrary  configurations  of  component  models  interconnected  by  various  flows. 
The  component  models  can  also  be  quite  arbitrary  in  their  modeling  sophistication  with  new  models  being  easily 
added  by  the  user.  The  flows  arc  likewise  arbitrary  in  their  complexity  and  may  represent  actual  physical  flows, 
such  as  gasses  or  liquids  in  the  ease  of  a  power  system,  or  simply  the  flow  of  information  in  the  case  of  a  sensor 
or  control  system.  GPS  also  permits  the  user  to  include  arbitrary  system  constraints  over  part  or  all  of  the  sys¬ 
tem  under  consideration.  In  fact,  difL.m  system  constraints  may  be  imposed  on  any  collection  of  user  defined 
nested  or  unnested  subsystems.  Additionally,  GPS  permits  the  user  to  define  nonlinear  objective  functions  to  be 
minimized  subject  to  both  equality  or  inequality  nonlinear  constraints  over  any  collection  of  subsystems.  These 
types  of  capabilities  permit  one  to  quickly  set  up  and  perform  an  almost  endless  variety  of  system  scenario  stu¬ 
dies. 

GPS  was  developed  to  make  use  of  the  various  component  models  previously  developed  for  use  within  the 
SALT  (System  Analysis  Language  Translator)  code  [1,2).  Thus,  a  number  of  component  models  for  power  sys¬ 
tems  arc  currently  available.  In  addition,  a  number  of  fluid  properties  procedures  arc  also  available  for  use  with 
those  models.  Several  of  these  model  libraries  arc  described  in  this  report.  In  order  to  use  GPS  with  any  set  of 
models,  there  arc  several  requirements  to  which  the  models  must  conform.  However,  these  requirements  arc  not 
complex,  and,  in  general,  simply  amount  to  adding  a  mechanism  to  locate  model  variables  and  functions  via 
their  names. 


GPS  has  a  number  of  advantages  over  the  SALT  code.  SALT  originally  made  use  of  a  preprocessor  tech¬ 
nique  in  its  PL/I  version  and  in  its  C++  version  required  the  user  to  simply  write  a  driver  using  the  various  C++ 
model  classes.  In  either  ease  the  resulting  driver  had  to  be  compiled  and  then  linked  to  the  component  models, 
mathematical  utilities,  property  procedures,  etc.  GPS  drivers  arc  interpreted  rather  than  compiled,  thus  saving 
the  resulting  compile  and  load  times  on  the  computer,  and  permitting  very  rapid  turn  around  times  in  performing 
a  scries  of  system  studies.  Another  advantage  that  GPS  affords  over  the  SALT  code  is  its  ability  to  interrupt  die 
execution  of  a  system  problem  and  then  query  and  change  system  variables. 


As  an  alternative  to  directly  writing  drivers  for  the  SALT  code,  GPS  is  itself  one  of  several  alternative 
ways  of  developing  non-preprocessor  methods  for  analyzing  systems.  For  example,  a  general  purpose  driver 
could  be  written  and  linked  to  the  models  which  would  provide  a  number  of  different  system  configurations, 
possible  system  constraints,  parametric  studies,  etc.  This  is  an  approach  often  employed  by  system  codes  and 
results  in  the  easiest  to  use  code  in  as  much  as  the  inputs  must  take  a  fixed  format.  This  approach  also  makes 
for  a  robust  code.  However,  even  the  most  general  hardwired  drivers  have  limitations  which  arc  usually  encoun¬ 
tered  eventually.  Another  alternative  would  be  to  develop  a  general  purpose  interpreted  language  for  interacting 
with  system  models.  This  provides  for  handling  a  greater  range  of  potential  system  problems  provided  that  the 
developed  language  is  sufficiently  flexible.  In  order  to  obtain  tins  flexibility  most  of  the  capabilities  of  a  general 
purpose  programming  language  must  be  provided.  This  means  that  a  relatively  sophisticated  language  parser 
must  be  developed.  As  a  third  alternative,  a  language  like  PostScript  or  Forth  might  be  employed  in  which 
there  is  relatively  little- syntax  structure  and  thus,  dees  not  need- a  sophisticated  parser.  These  language  ate  uLo 
extensible  providing  for  even  greater  flexibility.  However,  these  languages  have  a  disadvantage  in  that  they  are 
often  hard  to  read  due  to  their  use  of  postfix  notation  and  of  stacks.  While  these  disadvantages  can  not  be 
entirely  eliminated,  with  some  suitable  extensions  to  the  language  and  some  discipline  in  writing  input  they  can 
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be  reduced.  GPS  makes  use  of  this  last  alternative. 

The  next  section  presents  an  overview  of  the  GPS  language  and  some  of  its  differences  with  PostScript. 
The  third  section  presents  a  brief  discussion  of  the  PostScript  like  language  operators  followed  by  a  .section  on 
the  new  operators  for  dealing  with  models  developed  in  C. 


1.2.  GPS  Overview 

The  GPS  language  is  structured  exactly  as  the  PostScript  language  with  the  few  differences  discussed  below. 
Thus,  [  ]  delimit  arrays,  {  }  delimit  procedures,  and  a  /  delimits  literals.  A  %  sign  marks  the  beginning  of  a 
comment,  which  is  terminated  by  a  newline  mark.  GPS  makes  use  of  dictionaries  and  a  dictionary  staek  as  with 
PostScript,  with  systcmdict  containing  all  of  the  builtin  operators  and  userdiu  die  first  of  any  user  defined  dic¬ 
tionaries.  These  two  dictionaries  can  not  be  removed  from  the  dictionary  stack.  The  dictionary  stack  can  hold 
up  to  20  dictionaries,  the  operand  stack  up  to  500  elements,  and  the  execution  slack  up  to  250  elements.  The 
uscrdict  is  initially  defined  to  hold  up  to  200  user  defined  entries.  In  GPS,  however,  no  new  words  can  lie  added 
to  the  systemdieL 

At  present,  GPS  implements  roughly  60  of  die  PostScript  operators  and,  in  addition,  about  a  du/on  oilier 
operators  for  dealing  with  model  classes  and  die  mathematical  utilities  currently  widiin  SALT.  The  full  list  of 
PostScript  like  operators  is  given  in  the  next  secdon.  Here  we  present  some  of  the  differences  between  GPS  and 
PostScript. 

The  first  major  difference  between  GPS  and  PostScript  is  that  many  of  the  operators  widiin  PostScript 
have  not  been  implemented  simply  because  they  were  not  needed  for  the  purposes  for  which  GPS  is  envisioned. 
These  include  all  of  the  imaging  operators,  such  as  lincto,  moveto,  stroke,  show,  etc.,  many  of  the  file  operator,,, 
and  the  error  handling  operators,  such  as  stopped,  stop,  etc.  Some  of  these,  notably  the  error  handling  operators, 
may  eventually  be  added  to  GPS.  Note  the  intenuon  of  GPS  is  not  to  compete  widi  PostScript  but  rather  to 
have  a  way  of  interacting  with  the  SALT  code  models  in  an  interpreted  way  while  still  maintaining  die  full 
capabilities  afforded  by  an  actual  C++  driver.  Secondly,  character  strings  within  GPS  are  delimited  by  double 
quotes  "  "  as  in  C  or  C++.  This  frees  up  the  use  of  parenthesis  for  another  purpose  which  is  the  diird  main 
difference.  Any  collection  of  words  that  define  an  algebraic  expression  may  be  enclosed  within  parenthesis,  in 
which  case  the  expression  can  be  written  in  the  usual  infix  notation.  Thus,  the  expression 

((x+y)*sin(ln(x)+ l)-2*cos(x*y)) 
can  be  written  exaedy  as  is  rather  than 

x  y  add  x  In  1  add  sin  mul  2  x  y  mul  cos  mul  sub 

as  in  PostScript.  This  can  greatly  improve  the  readability  of  die  language  when  used  to  define  algebraic  expres¬ 
sions. 

Anodier  difference  between  GPS  and  PostScript  is  that  GPS  keeps  a  reference  count  of  all  arrays,  pro¬ 
cedures,  and  dictionaries,  objects  that  u.>e  what  PostScript  calls  virtual  memory.  These  objects  are  allocated  in 
memory  and  arc  pointed  to  by  possibly  many  odicr  objects.  The  number  of  objects  dial  have  a  reference  to  one 
of  diese  virtual  memory  objects  is  kept  track  of  and  stored  with  die  object.  When  this  reference  count  becomes 
zero  the  memory  occupied  by  die  object  is  freed.  Thus,  the  GPS  code  automatically  performs  its  own  garbage 
collection  and  the  usual  save  and  restore  type  operadons  used  in  PostScript  are  not  used. 

Finally,  there  are  a  few  minor  differences  between  the  GPS  operators  and  the  PostScript  operators.  These 
differences  will  be  discussed  within  of  the  next  section. 


1.3.  PostScript  like  operators 

As  many  of  the  GPS  operators  arc  exaedy  like  their  PostScript  counterparts,  diis  section  simply  enumerates 
these  operators,  referring  die  leader  to  the  PostScript  Language  Reference  manual  [3j  for  dicir  deluded  usage. 
These  operators  arc  listed  in  Table  1  which  is  followed  by  a  very  brief  introduction  to  the  use  of  these 
PostScript  like  operators. 


The  best  way  to  understand  the  various  GPS  operators  is  to  sec  how  they  are  used  in  some  examples. 
Thus,  we  present  some  very  simple  examples  making  use  of  only  those  operators  that  occur  in  Table  1  in  an 
intcracdve  GPS  session. 
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GPS  is  started  as  an  interactive  session  by  simply  typing  GPS.  The  "gps>"  prompt  will  then  appear  and 
any  valid  GPS  input  can  be  input  in  a  free  form  way.  Alternatively,  the  input  can  be  typed  into  a  file,  edited, 
and  saved,  then  a  GPS  session  can  be  started  and  the  GPS  run  operator  used  to  simply  execute  the  file.  That  is, 
after  the  "gps>"  prompt,  simply  type 

"file  name"  run 

Note  the  run  operator  can  also  be  used  to  initialize  the  system  by  simply  executing  a  file  containing  any  user 
defined  words,  dictionaries,  abbreviations,  or  whatever.  To  terminate  the  GPS  session,  simply  type  the  quit 
operator. 


Table  1.  GPS  operators  similar  to  PostScript 


abs 

add 

aload 

and 

array 

astore 

begin 

ceiling 

clear 

clcartomark 

copy 

cos 

count 

counldictstack 

counttomark 

currcntdict 

def 

diet 

div 

dup 

end 

eq 

cxch 

exit 

false 

floor 

for 

forall 

gc 

get 

gt 

if 

ifclse 

index 

lc 

length 

In 

loop 

log 

It 

maxlcngth 

mod 

mul 

ne 

neg 

not 

or 

pop 

nut 

quit 

repeal 

roll 

run 

sin 

sqrt 

stack 

store 

sub 

systemdict 

true 

jm _ 

uscrdict 

= 

GPS  also  has  an  interrupt  mode  which  is  initiated  by  typing  a  Control-c  character  at  the  terminal.  When 
this  mode  is  in  effect  the  prompt  is  changed  to  "gps_int>".  Any  GPS  input  is  equally  valid  in  this  interrupt 
mode,  including  the  quit  operator  which  will  terminatethe  session  just  as  in  the  normal  mode.  To  go  back  to 
the  normal  mode  from  the  interrupt  mode  simply  type  resume. 

When  GPS  is  reading  input  from  the  standard  input  file  any  errors  that  arc  found  arc  reported  and  the  ses¬ 
sion  continues.  If  an  error  does  occur  the  operand  stack  should  probably  be  cleared  (i.c.  simply  type  clear  )  or 
examined  (i.e.  type  stack  to  print  out  the  current  stack)  before  more  input  is  typed  in.  When  GPS  is  reading 
from  a  file  different  from  the  standard  input  file  any  errors  that  occur  are  again  reported,  but  in  this  ease,  the 
GPS  session  is  terminated. 

GPS  like  PostScript  makes  use  of  a  postfix  notation,  .imilar  to  a  "rcvcrsc-Polish"  calculator  and  thus 
requires  some  getting  use  to.  In  general,  numbers,  character  strings,  and  literals  (words  starling  with  a  '/')  are 
simply  pushed  onto  an  operand  stack.  Operators  pop  their  arguments  off  of  the  stack,  perform  their  function, 
and  then  push  their  results  back  onto  the  stack.  Thus,  the  input 

gps>  2  3  add  = 

would  push  2,  then  3  onto  the  stack,  the  add  operator  would  then  pop  the  3  then  the  2  from  the  stack,  add  them 
and  push  5  back  onto  the  stack.  The  =  operator  would  then  pop  the  5  from  the  stack  and  display  it  on  the  con¬ 
sole.  Any  of  the  arithmetic,  logarithmic,  exponentiation,  and  trigonometric  operators  can  be  used  in  a  similar 
way.  For  example: 

gps>  2  sin  ,3  *  = 

2.7279e+00 


gps>  1  log  = 
0.0000e+00 


gps>  1.0  1.0  atan2  = 


4 


7.8540C-01 

Thus,  GPS  can  be  used  as  a  calculator.  Since  algebraic  expressions  written  in  postfix  notation  arc  not  real  clear, 
expressions  can  also  be  written  in  the  usual  infix  notation  if  they  are  inclosed  in  parenthesis.  Thus  the  above 
examples  could  be  written  as  follows. 

gps>  (2+3)  = 

5.0000c+00 


gps>  (3*sin(2))  = 
2.7279c+00 


gps>  (log(l))  = 

0.0000e+00 


gps>  (atan2(l. 0,1.0)) = 

7.8540e-01 

Variables  can  be  assigned  a  name  and  defined  as  a  word  in  a  dictionary.  This  is  done  by  first  putting  the 
name  of  the  word  onto  the  stack  as  a  literal  (i.c.  prefix  by  followed  by  the  word’s  meaning,  and  then  fol¬ 
lowed  by  the  def  operator.  The  def  operator  will  pop  the  preceding  two  elements  from  die  stack  and  place  die 
definition  into  a  diedonary.  Thus,  to  define  x  to  be  2.0  one  would  write 

gps>  /x  2.0  def 

Actually,  each  such  defined  word  appears  within  one  or  more  dictionaries  on  a  dictionary  stack.  The  def  opera¬ 
tor  places  newly  defined  words  into  the  topmost  dictionary  on  this  stack  which  is  known  as  die  currentdict. 
Once  defined,  the  word  can  be  used  in  any  place  dial  its  defined  meaning  can  be  used.  Thus,  x,  defined  above  as 
the  number  2.0,  can  then  lie  used  in  any  algebraic  expression.  For  example, 

gps>  (x*x-l)  = 

3.0000c+00 

To  redefine  x  to  some  new  value  simply  reuse  die  def  operator.  Def  always  checks  to  sec  if  a  word  already 
exists  in  the  currentdict  first  before  creating  a  new  word.  TTius, 

gps>  /x  (x-1)  def 

would  replace  the  definition  of  x  to  be  the  value  of  x-1.  Often  the  value  of  a  word  to  be  defined  will  appear  on 
the  stack  before  the  literal  representation  of  the  word.  In  these  cases  the  excli  operator  is  useful.  For  example, 

gps>  12  /x  cxch  def  x  = 

1.2000c+01 

The  exch  operator  simply  exchanges  die  top  two  stack  elements.  There  arc  other  stack  manipulation  operators  - 
pop,  dup,  index,  copy,  roll,  clear,  cleartomark,  =,  and  stack  which  all  work  like  their  PostScript  counterparts. 
Briefly,  pop  deletes  die  top  stack  value,  dup  duplicates  the  top  stack  value  and  pushes  it  onto  the  stack,  index 
takes  a  number  from  the  stack,  counts  down  the  stack  by  that  number,  and  then  duplicat''"  <at  stack  clement  on 
top  of  the  stack,  copy  takes  a  number  from  the  stack  and  then  duplicates  that  many  stacx  elements  on  top  of  die 
stack,  roll  takes  two  numbers  from  die  stack,  the  first  the  number  of  stack  rotations  and  the  second  represents 
the  number  of  stack  elements  to  rotate.  Here  a  rotadon  is  a  circular  shifting  of  the  top  clement  to  die  bottom  and 
each  other  clement  moving  up  one  slot  on  the  stack.  When  the  number  of  stack  rotations  is  negauve  die  rota¬ 
tions  arc  performed  in  the  opposite  direction  widi  the  bottom  element  moving  to  the  top  and  each  other  element 
moving  down  one  slot  on  the  stack.  Clear  deletes  the  entire  stack,  cleartomark  deletes  down  to  a  T  mark,  = 
pops  the  top  stack  element  and  displays  it  (a:  best  as  it  can)  on  the  console,  and  finally,  stack  displays  the  entire 
stack  on  the  console  while  leaving  the  stack  unchanged. 

There  is  aiso  another  operator  lor  defining  words  into  a  dictionary  called  store.  Store  differs  from  def  m 
that  if  the  word  being  defined  does  not  appear  within  die  currentdict,  all  other  dictionarys  on  the  dictionary  stack 
arc  searched  for  the  word.  If  found  in  any  of  the  dictionaries  it  is  replaced,  otherwise,  the  word  is  added,  as  a 
new  definition  within  the  currentdict. 


s 


The  dictionary  stack  is  completely  separate  from  the  operand  stack  oad  is  used  to  define  the  context  in 
which  the  user  defined  words  arc  interpreted.  A  die. ionary  can  be  created  by  using  the  die.  operator  which 
takes  an  integer  from  the  operand  stack  represenung  die  number  of  words  the  diuionaiy  is  to  haul.  Vhe  diction¬ 
ary  itself  is  then  left  on  the  operand  stack  and  tan  be  given  a  name  and  stored  in  the  current  ha  or  ar.y  ether 
dictionary.  For  example, 

gps>  /mydict  20  diet  def 

defines  mydict  to  be  a  dictionary  to  hold  20  words.  The  dictionary  stack  itself  can  be  manipulate  1  by  using  the 
operators  begin  and  end.  Begin  takes  a  dictionary  from  the  operand  stack  and  pashes  it  to  the  dictionary  slack 
where  it  becomes  the  cunrentdict.  End  pops  the  topmost  dictionary  from  lac  dictionary  stack  and  makes  the  dic¬ 
tionary  below  it  on  the  dictionary  stack  the  currentdiet.  Thus, 

mydict  begin 
end 

can  be  used  to  define  a  local  context  with  rnydic'  as  the  cuncntdict.  Note  any  newly  defined  words  using  def', 
used  between  the  begin  and  end  would  then  K  placed  in  mydict.  Likewise  any  words,  referenced  between  die 
begin  and  end  would  be  searched  for  within  the  dictionary  stack  starting  with  mydict.  When  GPS  is  started  two 
dictionaries  are  on  the  dictionary  stack,  systemdict  which  actually  holds  ail  of  the  buillin  operate;  s,  -  add.  sub, 
mul,  div,  sin,  cos,  etc.,  and  uscrdict  which  is  initially  empty  but  can  hold  up  to  200  words.  These  two  dic¬ 
tionaries  cannot  be  popped  off  of  the  dictionary  stack  using  the  end  operator.  The  words  systemdict,  usmlict, 
and  currentdict  arc  also  operators  which  push  onto  the  operand  stack  their  corresponding  dictionaries. 

As  the  above  tends  to  imply  words  can  be  defined  to  hold  anything  within  the  language,  such  as  the 
mydict  dictionary,  and  not  just  numbers.  Thus, 

gps>  /y  "this  is  a  string"  def 
gps>  /z  (2  cxch  sin  *}  def 
gps>  /u  [1  2  3  4j  def 

defines  y  to  be  a  character  suing,  z  to  be  a  procedure,  and  u  to  be  an  array.  Procedures  and  arrays  arc  com¬ 
posed  of  user  defined  words,  literals,  operators,  and  even  other  procedures  and  arrays.  Procedures  arc  delimited 
by  curly  braces  and  arrays  by  square  brackets  (similar  to  Q.  Both  can  be  manipulated  as  a  single  stack  element 
once  their  right  delimiter,  either  ’)’  or  ’]’  is  encountered.  The  main  difference  between  the  two  is  that  as  pro¬ 
cedures  arc  input  a  deferred  slate  of  execution  exists.  That  is,  words  used  within  the  procedure,  as  it  is  being 
input,  arc  not  executed.  The  words  arc  simply  collected  into  a  single  operand  stack  element.  Procedure  execu¬ 
tion  only  occurs  when  some  other  word  explicitly  executes  the  procedure  such  as  when  a  named  procedure  is 
referenced  or  used  in  a  flow  control  construct.  For  example,  using  the  definition  of  z  above,  the  input 

gps>  10  z  = 

-1.0880C+00 

would  evaluate  2.*sin(10)  and  print  die  results.  Note  that,  due  to  this  deferred  execution,  procedures  may  con¬ 
tain  words  that  have  not  yet  been  defined.  However,  all  procedures  that  are  executed  will  require  that  each 
word  within  them  be  defined,  otherwise  the  undefined  error  will  occur. 

GPS  has  a  number  of  execution  flow  control  constructs,  similar  to  the  C  language’s  for,  while,  if,  and  if- 
clsc  statements.  Very  briefly,  these  constructs  include  die  if,  ifelse,  for,  repeat,  loop,  and  while  operators.  The 
operand  stack  syntax  for  their  use  is  defined  as  follows. 

cond  (  ...  }  if 
cond  {...}(  ...  }  ifelse 
start  ine  bound  {  ... }  for 
count  {  ...  }  repeat 
{  ...  }  loop 
{...){  ...  }  while 

Here  the  "{ ...  }"  indicate  an  arbitrary  GPS  procedure  and  should  be  thought  of  as  a  single  slack  element,  "cond" 
is  cidicr  a  true  or  false,  "count",  "start”,  "ine",  and  "bound"  are  numbers.  In  each  ease  the  preceding  stack  ele¬ 
ments  before  the  operator  are  popped  from  the  stack  before  the  operators  arc  executed.  These  ojwralors  work  as 
follows.  The  if  operator  checks  "cond",  if  true  it  executes  the  procedure.  The  ifelse  operator  checks  "cond",  if 
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true  it  executes  the  first  procedure,  if  false  it  executes  the  second  procedure.  The  for  operator  pushes  onto  the 
stack  a  value  beginning  with  "start"  and  then  executes  the  procedure.  The  value  is  then  incremented  by  "inc", 
pushed  onto  the  stack,  and  the  procedure  rccxecutcd.  This  continues  until  the  value  has  been  incremented 
beyond  the  "bound"  value.  The  repeat  operator  executes  the  procedure  "count"  times.  The  loop  operator  exe¬ 
cutes  the  procedure  indefinitely.  Note  in  this  case  the  builtin  exit  operator  must  be  used  to  terminate  the  loop. 
The  exit  operator  would  be  somewhere  within  the  procedure,  probably  within  an  if  or  ifelsc  construct.  Exit  can 
also  be  used  to  prematurely  terminate  the  for,  repeat,  and  while  loops  also.  The  while  operator  is  not  similar  to 
anything  within  the  current  PostScript  language  and  will  be  discussed  within  the  next  section.  One  other  looping 
operator  exists  that  takes  an  array  or  dictionary  as  an  argument  in  addition  to  a  procedure,  this  is  the  forall 
operator, 

[...]{  ...  }  forall 

diet  {  ...  }  forall 

Here  each  element  within  the  array  is,  in  turn,  pushed  onto  the  stack  and  the  procedure  is  executed.  In  the  dic¬ 
tionary  case,  each  word  and  its  meaning  is,  in  turn,  pushed  onto  the  operand  stack  and  the  procedure  is  exe¬ 
cuted. 

In  forming  the  cond  value  used  in  the  if  or  ifelse  operators,  most  of  the  standard  logical  connectives  arc 
available  -  or,  and,  eq,  ne,  It,  le,  gt,  ge.  Each  of  these  take  two  stack  values  and  return  to  the  stack  a  true  or 
false.  Actually,  GPS  docs  not  have  the  boolean  type  and  true  is  really  a  1  and  false  is  a  0.  All  of  the  relational 
operators  work  with  numerical  data  values  and,  at  present,  no  checking  that  the  operands  are  numerical  is  done. 
Like  the  algebraic  expressions  relational  expressions  can  also  be  formed  within  parenthesis  in  an  infix  way. 
When  this  is  done  the  usual  C  representation  of  these  connectives  should  be  used  -  "II",  "==",  "!=",  "<", 

"<=",  ">",  and  ">=".  Thus, 

(x>=y  &&  x<=z) 

in  the  C  language  would  be  written  exactly  the  same  way  in  GPS.  However,  the  parsing  of  these  expressions  do 
not  have  the  same  precedence  rules  as  in  the  C  language.  Thus,  in  forming  expressions  using  both  the  relational 
operators  and  the  algebraic  operators  additional  parenthesis  should  be  used  to  clearly  reflect  the  intended  pre¬ 
cedence.  The  parser  works  on  both  the  algebraic  and  relational  expressions  at  the  same  time,  in  order  to  keep  it 
simple,  with  the  precedence  of  the  ">",  "<",  etc.  operators  the  same  as  or "/"  and  the  precedence  of 

the  "&&"  and  "II"  operators  the  same  as  "+"  or  The  two  operators  eq  and  ne  can  also  be  used  with  literals 
and  strings. 

In  addition  to  the  forall  operator  for  dealing  with  arrays,  there  arc  several  others.  Like  the  diet  operator 
there  is  an  array  operator  for  creating  arrays.  Array  takes  a  number  from  the  stack  representing  the  numbet  of 
elements  the  array  is  to  hold  aid  then  creates  an  array  of  that  sizc.  Thus, 

gps>  /myarray  10  array  def 

creates  myaray  as  an  array  of  ten  elements.  Arrays  created  this  way  arc  initially  empty.  Elements  within  the 
array  may  be  assigned  values  using  the  put  operator.  Put  takes  an  array,  an  array  element  index  (the  first  cle¬ 
ment  is  0  as  in  C),  and  a  value  from  the  stack  and  men  redefines  that  element  to  be  value.  Similarly  there  is  a 
get  operator  that  takes  an  array  and  an  array  clement  index  from  the  stack  and  then  returns  that  clement  from 
the  array  to  the  stack.  The  put  and  get  operators  can  -bo  be  used  to  pul  and  get  elements  from  a  dictionary.  In 
this  case  rather  than  an  clement  index,  a  literal  defining  the  dictionary  word  is  used.  In -this  regard,  put  is  a 
third  way,  besides  the  def  and  store  operators  for  defining  words  in  a  dictionary.  At  present,  unlike  PostScript, 
put  and  get  cannot  be  used  with  strings. 

Two  other  array  operators  arc  used  to  store  and  load  (to  the  stack)  whole  arrays.  The  first  is  called  astore 
which  takes  the  top  element  from  the  stack  which  should  be  an  array,  determines  it  length,  and  then  pops  from 
the  slack  enough  elements  to  fill  the  array.  The  ariay  with  its  newly  defined  elements  is  then  left  on  top  of  the 
slack.  The  second  operator  is  called  aloud  and  takes  the  top  stack  element  which  should  be  an  array,  and  then 
pushes  onto  the  stack  each  clement  of  that  array  followed  by  the  array  itself. 

At  times  it  is  useful  to  be  able  to  determine  the  type  of  word  that  appears  on  the  operator  stack.  The  type 
operator  can  be  used  for  this.  Type  takes  an  element  from  the  stack  and  returns  a  literal  with  one  of  the  follow¬ 
ing  names  -  numbertype,  nametype,  diettype,  array  type,  proctypc,  slringtype  or  unknowntype. 
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1.4.  Additional  GPS  Operators 

Some  additional  operators  which  arc  not  defined  in  PostScript  or  arc  sufficiently  different  from  those  in 
PostScript  arc  listed  in  Table  2.  Some  of  the  more  complex  of  these  arc  described  in  more  detail  below,  others 
arc  simply  abbreviations  to  the  PostScript  operators  so  that  the  usual  infix  notation  can  be  exploited  in 
parenthesized  expressions. 

The  trigonometric  functions  in  both  Tables  1  and  2  take  their  arguments  in  radians  rather  than  degrees  as 
in  PostScript.  The  additional  trigonometric  functions  and  the  pow  function  in  Table  2  all  correspond  to  their  C 
language  counterpart,  each  popping  the  arguments  that  they  need  from  the  stack.  For  those  functions  requiring 
two  arguments,  the  arguments  arc  placed  on  the  stack  in  the  order  that  the  C  function  requires.  Thus,  pow(x.y) 
in  C  would  be  x  y  pow  in  GPS. 


Table  2.  Additional  GPS  operators 

iSJtSSSill® 

meaning 

operator 

meaning 

+ 

abbreviauon  for  add 

- 

abbreviation  for  sub 

* 

abbreviation  for  mul 

/ 

abbreviation  for  div 

atan 

arc  tangent  funedon 

tan 

tangent  function 

atan2 

arc  tangent  funedon 

asin 

arc  sin  funedon 

acos 

arc  cos  function 

bind 

implements  operator  binding 

pow 

C  pow  function 

exp 

C  exp  funedon 

min 

minimum  of  two  values 

max 

maximum  of  two  values 

while 

implements  while  loop 

debug 

turns  on  debugging 

fopen 

C-like  fopen  funedon 

fclose 

C-like  fclose  funedon 

printf 

C-like  printf  function 

fprintf 

C-likc  fprintf  funedon 

sintrp 

signal  interrupt  mode 

resume 

resume  main  mode 

rangccheck 

turns  on  rangcchccking 

estack 

print  execution  stack 

The  while  operator  takes  two  procedures  from  the  stack  and  executes  the  first.  This  procedure  should 
return  cither  a  true  or  false  value  to  the  stack.  The  value  is  then  popped  from  the  stack  and  checked.  If  the 
value  was  true  the  second  procedure  is  executed  and  the  while  loop  executes  the  first  procedure  again  repeating 
the  process.  If  the  value  was  false  the  loop  is  terminated.  Note  that  the  true  or  false  returned  by  the  first  pro¬ 
cedure  is  consumed  by  the  while  operator  and  is  not  on  the  stack  when  the  second  procedure  is  executed  or 
when  the  loop  terminates.  However,  one  or  both  of  the  procedures  may  leave  other  values  on  the  stack.  This 
looping  operator  was  furnished  to  give  a  mechanism  similar  to  the  C  while  loop.  Basically,  the  C  language  con¬ 
struct 


becomes 


in  GPS. 


while  (condition)  (...) 


(condition)  (...)  while 


The  fopen  operator  is  similar  to  the  PostScript  file  operator  taking  two  character  string  arguments  from  the 
stack.  The  second  argument  popped  from  the  stack  is  the  name  of  the  file  and  the  first  argument  popped  from 
the  stack  is  the  mode  in  which  the  file  is  opened.  At  present,  only  "w"  for  writing  or  “a"  for  appending  arc 
valid  modes.  The  operator  leaves  on  the  stack  a  file  descriptor.  For  example, 

"file"  "w"  fopen 


will  open  a  file  named 


"file"  for 


writing,  leaving  the  file  descriptor  on  die  stack. 


The  fclose  operator  takes  a  file  descriptor  argument  from  the  stack  and  closes  the;associatcd  file. 

The  printf  operator  takes  either  one  or  two  arguments  from  the  stack.  If  the  top  stack  clement  is  an  array 
then  printf  pops  an  additional  stack  element  which  should  be  a  character  string  argument  representing  the  for¬ 
mal  control  of  a  C-likc  printf  function.  Like  the  C  format  control  string,  instances  of  %  followed  by  die  usual 
format  control  characters,  i.c.  c,  d,  f,  or  s  arc  recognized.  In  addidon  die  usual  escape  sequence  of  ’VT 
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corresponds  to  a  new  line  as  in  C.  For  each  occurrence  of  a  %,  a  corresponding  clement  of  the  array  argument 
will  be  printed.  For  example,  to  print  the  variables  x,  y,  z  with  the  C  format  string 

"x=%.2f  y=%5.4c  z=%d" 

one  would  write 

"x=%.2f  y=%5.4c  z=%d"  [x  y  z]  printf 

At  present  only  the  format  controls  e,  f,  d,  and  s  are  recognized.  Printf  can  also  be  called  with  just  a  format 
string  as  an  argument  if  no  variables  need  to  be  printed. 

The  fprintf  operator  is  exactly  like  the  printf  operator  except  that  an  additional  argument  is  required  on 
the  stack  before  the  format  string  representing  a  file  descriptor  obtained  from  the  fopen  operator.  For  example, 

fd  "Nnx=%e"  fxl  fprintf 

will  print  the  value  of  x,  labeled  by  "x=",  onto  the  file  associated  with  the  file  descriptor,  fd. 

The  bind  operator  is  used  to  bind  all  of  the  builtin  operator  names  that  appear  within  a  procedure  to  the 
operations  themselves.  This  prevents  looking  up  the  operators  within  systemdict  during  the  execution  of  a  pro¬ 
cedure  thus  speeding  up  its  execution.  Bind  takes  either  an  integer  or  a  procedure  from  the  stack.  If  its  argu¬ 
ment  is  a  procedure,  bind  performs  its  function  on  that  procedure  (but  excluding  any  nested  procedure)  and 
returns  the  procedure  to  the  stack.  If  its  argument  is  a  number,  it  should  be  cither  a  zero  or  one.  A  one  indi¬ 
cates  that  an  autobinding  should  take  place  for  every  procedure  as  it  is  defined.  A  zero  turns  off  this  autobind- 
ing  mechanism.  Initially  aulobinding  is  on.  Additionally,  binding  resolves  any  variable  defined  in  the  model 
classes  to  a  pointer  to  the  variable. 

The  debug  operator  is  used  to  set  the  level  of  debugging.  Debug  takes  the  top  stack  argument  as  the 
appropriate  debugging  level.  There  are  5  levels  of  debugging.  Zero  turns  off  any  debugging.  A  one  prints  out 
the  top  five  stack  elements  followed  by  the  current  word  being  executed.  These  words  are  preceded  by  the  word 
stack  and  three  comma  separated  numbers.  The  first  number  is  the  top  stack  clement  number,  the  second  is  the 
top  execution  stack  element  number  and  the  third  is  the  top  dictionary  stack  clement  number.  A  two  level 
debug  gives  the  same  as  level  one  plus  also  shows  the  elements  for  each  array  or  procedure.  A  three  gives  the 
same  as  the  two  icvcl  plus  shows  each  word  as  it  is  collected  into  procedures.  Finally,  a  four  gives  the  same  as 
level  three  plus,  shows  each  model  class  variable  that  is  bound  to  its  location  and  shows  the  virtual  memory 
counts  for  each  array,  procedure,  or  dictionary  as  well  as  their  hexadecimal  locations.  As  each  word  is  shown, 
cither  in  executing,  collecting,  or  binding,  both  the  name  (if  known)  and  the  type  arc  shown  with  the  type 
printed;  first  followed  by  the  name  separated  by  a  colon.  In  the  case  of  arrays,  procedures,  or  dictionaries,  the 
type  isTollowed  by  the  current  reference  count  for  the  object  separated  by  a  colon.  There  arc  a  number  of  type 
letters  that  can  presently  appear.  These  are  shown  in  Table  3.  Initially  debugging  is  off. 

The  sintrp  operator  is  used  to  take  the  GPS  interpreter  into  an  interrupted  mode.  When  this  operator  is 
called  GPS  suspends  its  current  execution  and  prompts  for  additional  GPS  input  from  the  console.  To  distin¬ 
guish  this  mode  from  the  normal  mode,  the  prompt  is  changed  to  "gps _int>".  Any  legitimate  GPS  input  can 


Table  3.  Word  types 

KmX 

meaning 

type 

meaning 

0 

type  not  yet  set 

L 

literal 

S 

character  string 

N 

number 

D 

dictionary 

A 

array 

P 

procedure 

0 

builtin  operator 

I 

infix  parenthesis  expression 

F 

file  descriptor 

d 

model  class  double  variable 

i 

model  class  int  variable 

s 

model  class  char*  variable 

c 

model  class  double  and  literal 

j 

model  class  ini  and  literal 

l 

model  class  char*  and  literal 

_S _ 

model  class  function  and  literal 

f 

model  class  function 
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then  be  entered.  This  input  is  kept  completely  separate  from  the  suspended  work  in  so  far  as  the  operand  stack 
is  concerned.  However,  all  the  user  defined  words,  dictionaries,  model  classes,  etc.  used  by  the  suspended  work 
can  still  be  used.  Thus,  sintrp  can  be  used  to  interrupt  the  execution  of  some  GPS  input  for  examining  vari¬ 
ables  or  even  reassigning  different  values  to  variables.  For  instance,  the  debug  operator  could  be  turned  on  or 
off.  However,  in  changing  variables  that  arc  being  used  in  some  sa^^nded  work,  one  should  be  careful  that 
such  changes  make  sense.  Thus,  the  use  of  sintrp  should  be  carefully  thought  out  before  the  GPS  input  is  exe¬ 
cuted.  An  example  of  the  use  of  sintrp  will  be  shown  in  the  next  chapter. 

At  times  it  is  useful  to  be  able  to  interrupt  the  execution  of  some  GPS  input,  not  from  within  the  GPS 
input  itself,  but  from  the  keyboard.  This  is  done  by  simply  typing  Control-c.  When  this  interrupt  signal  is 
caught  by  the  GPS  interpreter,  the  interrupt  mode  will  commence. 

The  resume  operator  is  used  to  resume  the  normal  processing  mode  when  in  tire  interrupt  mode.  The  pro¬ 
cessing  mode  that  is  resumed  is  exactly  that  which  was  executing  before  the  interrupt.  Thus,  if  a  file  was  being 
executed  with  the  run  operator,  that  file  execution  is  resumed. 

The  rangecheck  operator  is  used  to  suspend  checking  of  the  array  bounds  when  using  the  put  or  get 
operators  with  arrays.  The  operator  takes  one  argument  from  the  stack  which  should  be  either  a  0  for  turning 
off  rangcchccking  or  1  for  turning  on  rangcchccking.  Note,  that  like  many  other  codes,  if  rangechecking  is 
turned  off  and  the  bounds  arc  exceeded,  a  segmentation  fault  will  probably  occur.  Thus,  at  least  initially, 
rangechecking  should  probably  be  kept  on.  The  on  state  is  the  default.  The  ability  to  turn  off  rangcchccking  is 
provided  to  speed  up  execution  of  those  inputs  making  use  of  many  large  arrays. 

The  estack  operator  is  similar  to  the  stack  operator  only  it  prints  out  the  state  of  the  current  execution 

stack. 

Several  additional  operators  are  also  furnished  for  dealing  with  model  classes  and  the  mathematical  utili¬ 
ties  classes.  These  operators  arc  listed  in  Table  4.  Examples  of  their  usage  arc  presented  in  the  next  chapter. 
A  model  class  is  a  C  data  structure  and  a  collection  of  functions  that  take  a  pointer  to  that  structure  as  an  argu¬ 
ment.  Thus,  a  GPS  model  class  is  similar  to  a  C++  class.  An  instance  of  a  model  class  is  simply  an  allocation 
of  the  C  structure.  In  general  once  a  model  class  instance  has  been  allocated,  its  variables  can  be  used  just  like 
any  other  variable  within  the  GPS  input.  However,  in  order  that  GPS  can  determine  that  these  variables  arc 
model  class  variables  a  restriction  is  placed  on  the  names  that  variables  can  have  in  the  GPS  input.  Variables 
that  are  not  model  class  instances  must  never  have  a  embedded  within  their  names.  Variables  that  arc  model 
class  instances  are  referenced  exactly  as  they  would  be  in  C,  as  the  instance  name,  followed  by  ".".  followed  by 
the  variable  name.  The  additional  operators  will  now  be  explained. 

cinit  -  cinit  is  used  to  initialize  any  mechanisms  needed  by  the  model  classes  before  any  such  class  is 
defined.  This  operator  should  be  called  once  before  any  model  class  is  used  (i.e.  such  as  with  cnevv  ).  Cinit 
requires  no  stack  values  as  arguments  and  returns  no  stack  values. 

cnew  -  cnew  is  used  to  allocate  a  new  model  class  instance  and  store  it  on  a  special  stack  for  use  in 
referencing  its  member  functions  and  variables.  Cnew  requires  one  array  object  on  the  stack,  the  elements  of 


Table  4.  Operators  for  handling  GPS  model  classes 

lilWfCTifU 

meaning 

cinit 

cnew 

cdcl 

call 

vary 

cons 

icons 

mini 

diff 

initializes  model  class  interface  mechanism 
allocates  a  new  model  class  instance 
deletes  a  model  class  instance 
calls  a  modcl  class  member  function 
defines  variables  to  be  varied 
defines  equality  constraints 
defines  inequality  constraints 
defines  objective  functions  for  optimizations 
defines  differential  equations 
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which  are  a  literal  specifying  the  class  type,  a  literal  specifying  the  name  of  the  class  instance  and  zero,  one,  or 
more  pairs  of  elements  consisting  of  a  class  variable  name  specified  as  a  literal  and  a  value  foi  that  variable. 
For  example,  to  allocate  a  new  instance,  denoted  x,  of  the  model  class  abc,  and  to  assign  values  1,  2,  and  "abc" 
to  the  class  members  parml,  parm2,  parm3,  one  would  write 

[  /abc  /x  /parml  1  /parm2  2  /pami3  "abc"  ]  cncw 

Cncw  returns  no  stack  values.  Note  that  within  the  array  argument  to  cnew  the  model  class  variables  arc 
referred  to  without  being  qualified  by  the  instance  name  and  thus,  do  not  contain  the  embedded  Y.  Note  also, 
that  class  abc  may  have  many  other  vaiiablcs  besides  parml,  parm2,  and  parm3.  Not  all  of  the  class  variables 
have  to  be  initialized  with  cnew.  Additionally,  class  variables  do  not  have  to  explicitly  appear  within  a  cnew 
operation  in  order  that  they  may  be  referenced  later.  Thus,  once  a  class  instance  is  allocated  widi  cnew  all  the 
variables  of  the  class  can  be  referenced. 

cdel  -  cdel  is  used  to  free  up  any  model  class  instance  allocated  by  the  cnew  operator.  It  requires  one 
stack  value  which  is  the  name  of  the  class  instance  used  in  the  cnew  operator.  Thus,  to  free  die  instance  x  of 
class  abc  defined  in  the  previous  example,  one  would  write 

/x  cdel 

Cdel  returns  no  stack  values.  As  it  is  sometimes  necessary  to  free  all  of  the  variables  allocated  by  all  of  tire 
cnew  operations,  the  special  literal  value  /all  is  recognized  by  cdel.  In  this  case  all  of  the  model  classes  w  ill  be 
freed.  Once  a  class  is  freed  any  reference  to  it  will  be  flagged  as  an  undefined  error.  Cdel  used  with  the  /all 
argument  will  also  free  variables  that  might  have  been  allocated  with  cinit.  Thus,  cinit  would  have  to  be 
recalled  to  make  use  of  further  model  classes  in  the  same  input. 

call  -  call  is  used  to  reference  a  model  class  function  which  takes  arguments.  In  general,  a  model  class 
function  can  be  called  simply  by  specifying  its  name.  For  example,  if  model  abc  had  a  function  c  Liking  no 
arguments,  then  to  call  the  x  instance  of  that  function  one  would  simple  write  x.c  in  the  GPS  input.  However, 
suppose  the  model  also  had  a  function  d  taking  4  arguments  then  the  call  operator  should  be  used.  The  call 
operator  Likes  from  the  stack  an  array  of  values  representing  the  arguments  in  the  order  that  the  function 
requires  and  the  name  of  the  function  specified  as  a  literal.  For  instance 

[1  2  3  4]  /x.d  call 

Note  that  call  does  not  return  any  stack  values,  however  the  function  being  called  may  return  an  integer,  double, 
or  character  string,  which  will  be  simply  pushed  onto  the  stack.  At  present,  only  functions  w  ith  numerical  and 
string  arguments  may  be  called. 

vary  -  vary  calls  the  C  function  necessary  for  solving  systems  of  algebraic  equations  and  or  differential 
equations.  When  used  in  solving  algebraic  equations  vary  requires  four  stack  values  consisting  of  a  variable  to 
be  varied  specified  as  a  literal,  a  sta-ting  value,  a  lower  bound  value  and  an  upper  bound  value.  When  used  with 
differential  equations  vary  requires  two  stack  values  consisting  of  the  dependent  variable  of  the  differential 
equation  specified  as  a  literal  and  the  initial  value  of  that  variable.  Vary  does  not  return  any  values  to  the  stack. 

cons  -  cons  calls  the  C  function  used  for  defining  and  storing  system  constraints.  Cons  requires  two  stack 
values  consisting  of  a  variable  specified  as  a  literal  (this  is  used  to  delimit  this  constraint  from  others,  dial  is,  as 
a  constraint  label)  and  the  current  value  of  the  constraint  residual.  Cons  returns  no  values  to  the  suck. 

icons  -  icons  calls  the  C  function  for  defining  inequality  constraints  and  works  exaedy  as  cons,  requiring 
two  stack  values. 

mini  -  mini  call  the  C  function  for  defining  and  storing  objective  functions  used  in  optimizations  and 
requires  one  slack  value  representing  the  current  value  of  the  objective  function.  Mini  docs  not  return  any  values 
to  dm  stack. 

diff  -  diff  calls  the  C  function  for  defining  differential  cquauons  and  requires  two  stack  values.  The  first 
is  the  name  of  the  variable  to  be  integrated  written  as  a  literal  followed  by  die  current  value  of  the  variable’s 
derivative. 

Chapter  2  will  explain  the  use  of  the  vary,  cons,  icons,  mini,  and  diff  operators  in  more  detail,  along  with 
examples  of  their  use. 


CHAPTER  2 


General  Model  and  Mathematical  Ufh'lies  Classes 


2.1.  Introduction 

The  GPS  code  was  designed  to  analyze  systems  consisting  of  arbitrary  lumped  component  models  interconnected 
by  various  "flows”.  Most  often  these  "flows"  represent  actual  physical  flows,  such  as  gasses  or  liquids,  although 
they  may  just  represent  information  that  needs  to  be  passed  from  one  model  to  another.  The  models  represent 
discrete  entities  through  which  the  flows  pass.  In  physical  systems  these  entities  arc  the  pumps,  compressors, 
turbines,  nozzles,  diffusers,  heat  exchangers,  reactors,  mixers,  splitters,  etc.,  that  make  up  the  system.  The  inter- 
connectivity  of  the  models  by  the  flows  represents  the  system  configuration.  GPS  was  designed  to  handle  an 
arbitrary  system  configuration.  In  addition,  GPS  was  designed  to  let  the  user  impose  on  flic  system  arbitrary 
system  constraints,  parameter  sweeps,  optimization  studies,  etc.  In  this  chapter  we  consider  the  general  features 
of  the  model  and  utility  classes.  Later  chapters  will  discuss  specific  model  classes  for  handling  power  systems 
and  thermionic  systems.  There  arc  actually  several  different  collections  of  model  classes  with  each  collection 
being  stored  in  a  different  library  of  models. 

The  next  section  describes  some  general  conventions  used  by  the  different  classes  followed  by  a  section 
on  the  use  of  stacks.  The  fourth  section  discusses  the  task  class  and  its  member  functions.  This  class  is  one  of 
the  most  important  classes  in  that  it  is  the  controlling  mechanism  in  solving  most  system  analysis  problems. 
This  section  is  followed  by  a  section  giving  a  scries  of  examples  of  the  use  of  the  task  class. 

2.2.  Class  conventions 

A  model  or  utility  class  in  GPS  is  nothing  more  than  C  data  structure  and  a  collection  of  functions.  As  men¬ 
tioned  briefly  in  chapter  one,  the  C  variables  within  the  data  structure  are  referenced  within  the  GPS  input  as  the 
class  instance  name,  followed  by  a  and  then  the  variable  name,  that  is,  they  are  referenced  exactly  as  they 
would  be  in  C.  The  function  names  are  also  referenced^  within  the  GPS  input  in  the  same  way,  as  the  class 
instance  name,  followed  by  a  and  then  the  name  defining  the  function.  We  will  often  refer  to  flic  functions 
associated  with  a  class  as  member  functions  analogously  to  the  terminology  used  in  C++. 

The  elements  of  a  model  class  structure  may,  themselves,  be  instances  of  other  classes,  i.e.  substructures. 
For  example  the  substructure  holding  the  values  of  the  model  powers  and  flow  variables  are  treated  like  model 
classes.  Thus,  there  really  is  no  limitations  on  what  can  be  placed  within  the  model  class  structure.  For  unifor¬ 
mity,  the  actual  C  membr  reactions  of  the  class  are  usually  named  the  same  as  the  data  structure  followed  by  a 
suffix  delimiting  the  sjtccific  function.  Usually,  the  first  argument  to  these  functions  is  a  pointer  to  the  data 
structure. 

In  general,  the  model  classes  each  have  an  allocator  function  denoted  by  the  suffix  "new"  which  is  used  to 
allocate  an  instance  of  the  class  and  to  define  the  default  values  to  the  model  data  structure  members.  This  new 
function  requires  a  character  string  argument  which  represents  the  class  instance  name  and  is  stored  in  a  variable 
denoted  as  "name".  In  addition,  this  function  will  usually  place  the  model  onto  a  slack,  which  can  then  be  used 
to  manipulate  all  of  the  models  as  a  unit  All  of  the  models  have  a  calculational  function,  usually  denoted  by 
the  suffix  c,  and  a  printout  function,  denoted  by  the  suffix  print  The  calculational  function  is  where  the  actual 
model  equations  arc  solved.  In  addition,  each  of  the  models  has  a  ref  function  for  referencing  the  model  vari¬ 
ables  by  name.  This  ref  function  is  the  communicating  link  between  the  GPS  code  and  the  model  variables  and 
will  be  explained  in  more  detail  in  a  later  chapter. 

2.3.  C  Stacks 

The  model  and  utility  classes  make  much  use  of  various  stacks  for  storing  and  retrieving  information.  These 
stacks  arc  themselves  composed  of  a  data  structure  and  member  functions  and  thus,  are  themselves  model 
classes  as  we  are  defining  these.  These  slacks  arc  also  completely  different  titan  the  stacks  used  in  GPS.  The 
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GPS  stacks  arc  completely  under  the  control  of  the  user.  The  stacks  used  by  the  model  and  utility  classes  are 
only  controlled  by  the  user  in  an  indirect  way.  Thus,  as  mentioned  above,  when  a  new  model  instance  is  allo¬ 
cated  it  is  usually  placed  on  a  stack.  Whether  or  not  it  actually  is  is  dependent  on  the  specific  model.  When 
the  user  defines  system  constraints,  as  will  be  discussed  later,  these  constraints  arc  also  placed  onto  a  stack. 
Other  stacks  arc  used  to  hold  the  flows  that  arc  passed  from  model  to  model.  Some  of  these  stack*  have  specific 
names  that  can  be  referred  to  within  the  GPS  inputs.  For  example  the  stack  upon  which  the  models  arc  placed 
is  denoted  as  "mods".  This  stack  has  a  print  function  referenced  as  "mods.print",  which  when  called  will,  in 
tum,  call  the  print  functions  of  all  the  models  on  the  mods  stack.  Similarly,  the  stack  used  to  hold  die  gas  flows 
in  the  power  system  component  library  is  denoted  as  "gass".  A  similar  print  function,  "gass.print",  when  called 
will  produce  tables  of  the  all  the  gas  flows  within  the  system.  Each  model  class  library  will,  in  general,  have 
one  or  more  of  these  stacks  that  need  to  be  present  in  order  that  the  models  will  work  properly.  Hie  cinit  func¬ 
tion  is  used  to  allocate  and  properly  set  up  any  such  stacks  required  by  the  models. 

2.4.  Task  class 

The  task  class  is  used  to  set  up  and  control  the  iterations  used  by  the  mathematical  utilities.  The  current  set  of 
utilities  includes  a  hybrid  steepest  dcscent/quasi  Newton  update  technique  for  solving  systems  of  nonlinear  alge¬ 
braic  equations  [4],  a  sequential  quadratic  programming  technique  for  solving  nonlinear  constrained  optimisation 
problems  [5],  and  Gear’s  mcdiod  for  solving  systems  of  stiff  and  nonstiff  ordinary  differential  equations  [6]. 
The  task  class  makes  use  of  some  member  functions  to  collect  into  separate  stacks  the  problem  data  for  die  par¬ 
ticular  task  being  solved.  These  include  die  variables  being  varied  using  vary,  the  equality  constraints  using 
cons,  the  inequality  constraints  using  icons,  the  objective  functions  using  mini,  and  differential  equations  using 
diff.  When  die  controlling  function  of  the  task,  denoted  as  c,  is  called,  it  determines  the  type  of  problem  dial 
has  been  set  up,  allocates  die  appropriate  work  space,  and  then  calls  the  appropriate  mathematical  utility.  While 
the  details  of  die  cquadon  solvers,  optimizers,  and  ODE  solvers  is  beyond  the  scope  of  this  document,  the  task 
variables  should  be  understood  to  effectively  use  the  task  class  within  the  GPS  input. 

The  complete  list  of  user  variables  for  the  task  class  is  given  below.  For  each  variable  an  indication  of 
whether  die  variable  is  an  input  or  output  is  given,  along  with  its  default  value  specified  in  parendicsis. 

maxit  -  integer  defining  the  maximum  number  of  iterations  that  are  allowed  in  solving  equations  and  in 

performing  optimizations  (40).  Input  Maxit  should  be  less  than  1000,  as  iteration  counts 
greater  than  dial  have  a  special  meaning  the  the  cquadon  solver  and  optimizer. 

prt  -  integer  specifying  various  amounts  of  output  be  printed  during  the  iterations  that  the  task  is 

performing  (2).  InpuL  The  value  zero  will  tum  off  all  printing  requiring  dial  any  output  be 
generated  explicitly  by  die  GPS  input  Values  greater  than  zero  will  produce  greater  and 
greater  amounts  of  output.  The  actual  output  that  is  generated  is  dependent  on  the  task  being 
solved  and  also  requires  for  its  interpretadon  a  greater  understanding  of  the  mathematical  utili¬ 
ties  than  can  be  quickly  explained  here.  However,  the  default  value  of  2  provides  for  a  reason¬ 
able  amount  of  output  for  most  tasks  and,  as  this  is  the  default,  this  level  of  output  will  be 
explained. 

For  the  equation  solving  tasks  the  following  is  obtained.  For  each  iteration,  die  output  will  con¬ 
sist  of  the  task  name  (as  furnished  by  the  user  within  the  GPS  input)  labeled  as  (task:),  the 
iteration  number  labeled  as  (n=),  and  the  square  root  of  the  sum  of  die  squares  of  die  constraint 
residuals  labeled  as  (f=).  Note  that  this  last  value  should  gradually  be  reduced  to  zero  as  die 
iterations  proceed.  Following  these  values  is  the  list  of  independent  variable  values,  i.c.  the 
unknowns  of  the  problem,  labeled  as  (x=)  and  the  list  of  constraint  equation  residuals  labeled 
as  (c=).  This  last  list  of  numbers  should  also  gradually  be  reduced  to  zero  as  die  iterations 
proceed.  Following  diese  items  is  a  line  of  output  giving  some  values  of  Newton  step  norms, 
steepest  descent  step  norms,  etc.  Only  one  of  these  will  be  important  in  most  eases,  and  that  is 
the  variable  labeled  as  (mu=).  This  variable  gives  some  measure  of  the  ratio  of  Newton  step 
versus  steepest  descent  step  and  will  generally  be  a  small  number,  (less  dtan  about  3)  if  die 
equations  solver  is  not  having  problems.  If  mu  becomes  larger  (greater  than  10)  dicn  one 
should  reconsider  the  problem  being  solved.  For  example,  it  might  be  singular  or  not  even 
have  a  solution. 


13 


For  the  optimization  tasks,  the  outputs  give  the  task  name  (task:)  and  the  iteration  number  (it). 
The  number  of  equality  constraints  (mcq=)  and  the  objective  function  value  (f=)  are  then  given. 
The  next  line  (x-)  give  the  values  of  the  independent  variables.  The  (c=)  line  then  gives  die 
values  for  the  constraints  with  the  equality  constraints  specified  first,  followed  by  the  inequality 
constraints.  Note  that  unlike  the  equation  solver  ta''-'?,  the  number  of  independent  variables 
and  constraints  may  be  different.  A  line  labeled  as  (1=)  gives  the  value  of  the  terminations 
function  (a  function  similar  to  the  gradient  of  the  Lagrangian  only  with  absolute  values  within 
its  sums).  When  this  value  is  less  than  the  specified  task  accuracy  the  problem  is  considered 
solved.  The  value  of  1  is  only  calculated  after  a  quadratic  subproblcm  has  been  solved  and 
thus,  does  not  appear  on  ever  iteration.  Some  of  the  iterations  arc  line  searches  which  will 
include  a  output  line  that  gives  the  number  of  the  line  searches  (nf=)  plus  several  other  param¬ 
eters  pertinent  to  the  line  search. 

For  integration  tasks,  again  the  task  name  labeled  as  (task:)  is  given  followed  by  the  current 
time  (t=),  the  integrator  state  (statc=)  and  integration  order  (order=).  The  next  line  labeled  as 
(x=)  gives  the  dependent  variable  values  and  the  last  line  gives  the  dependent  variable  deriva¬ 
tives  (dxdt=). 

acc  -  variable  holding  the  termination  accuracy  critcria(lc-3).  Input.  For  equation  solving  tasks 

when  ever  die  square  root  of  the  sum  of  the  squares  of  the  constraint  residuals  becomes  less 
than  acc  the  iterations  arc  terminated. 

del  -  variable  indicating  the  amount  of  perturbation  that  the  independent  variables  will  undergo  when 

the  equation  solver  or  optimizer  is  calculating  gradients  of  the  constraints  (le-7).  Input. 

meth  -  method  used  by  the  ODE  integrator  indicating  whether  Gear’s  backward  differencing  method  if 

1  or  the  Adams-Bashford-Moulton  method  if  0  is  to  be  used  (1).  Input. 

state  -  variable  indicating  the  state  of  the  ODE  intcgrator(O).  Input.  Initially  this  variable  is  0  indicat¬ 

ing  to  the  integrator  to  start  the  integration.  On  output  it  is  assigned  a  value  from  1  to  7  indi¬ 
cating  the  type  of  step  that  the  integrator  is  performing.  This  variable  should  be  manually 
reset  to  zero  at  the  start  of  an  integration  task  if  one  is  performing  an  iterative  loop  around 
such  a  task.  State  values  of  1  indicate  that  the  integrator  has  reached  a  specified  output  time. 
State  values  of  2  indicate  that  the  integrator  has  reached  a  time  value  for  which  the  dependent 
variables  arc  known  to  the  requested  accuracy.  These  two  values  of  state  are  the  only  ones  for 
which  it  is  guaranteed  that  the  time  values  reached  will  not  become  smaller.  For  all  other  state 
values,  the  integrator  may  be  performing  iterations,  jacobian  evaluations,  or  other  functions  for 
which  a  later  step  might  actually  be  done  for  an  earlier  time  value.  This  would  be  the  case, 
for  instance,  if  the  integrator  could  not  maintain  the  requested  accuracy  for  the  current  integra¬ 
tion  step  and  had  to  reduce  it.  This  is  mentioned  because  it  is  often  desirable  to  print  out  some 
variables  while  an  integration  is  being  performed,  and  it  is  only  when  state  is  1  or  2  that  die 
print  out  of  such  variables  would  make  sense. 

time  -  variable  indicating  the  present  value  that  the  variable  being  integrated  over  has  reached  (0). 

Input  on  the  first  call.  On  output  time  will  contain  the  current  time  reached  during  the  integra¬ 
tion.  This  variable  should  also  be  manually  reset  if  the  integration  task  is  repeated  within 
some  iterative  loop.  Note  that  this  variable  is  denoted  as  time  since  very  often  time  is  die 
independent  variable  for  the  integration.  This,  however,  docs  not  preclude  using  the  integrator 
for  integrating  over  other  variables,  they  must  just  be  denoted  as  time. 

tout-  variable  indicadng  the  output  value  to  which  the  integrations  will  condnuc  (1.0).  Input.  If 

several  output  times  arc  required,  the  integration  task  should  simply  be  put  within  an  iterative 
loop  over  tout.  Note  that  this  loop  does  not  repeat  the  integradons  from  their  start  so  time  and 
state  should  not  be  reset  to  zero  in  this  case. 

Class  task  also  has  five  primary  member  functions,  vary,  cons,  icons,  mini,  and  diff.  (Note,  that  these 

functions  arc  used  so  often  that  the  normal  class  naming  convcndon  of  prefixing  them  widi  "task"  is  not  used.) 

These,  as  briefly  explained  within  the  introduction,  arc  used  to  setup  the  various  task  types.  Each  of  these  func¬ 
tions  should  lie  within  a  loop  controlled  by  the  c  function  of  the  task.  This  controlling  function  should  be  called 

before  any  of  the  member  functions  are  called  and  returns  a  one  if  the  task  is  not  yet  satisfied  (i.e.  equations  not 
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yet  solved  or  integration  output  time  not  yet  reached)  and  a  zero  when  the  task  is  satisfied.  The  easiest  way  to 
use  this  function  within  the  GPS  input  is  to  place  the  c  call  within  a  while  statement: 

(x.c) 

{ 

"task  body" 

) 

while 

where  x  refers  to  the  actual  task  object  that  has  been  declared  for  this  task  and  "task  body"  will  define  the  prob¬ 
lem  to  be  solved  using  the  vary,  cons,  mini,  etc.  GPS  operators. 

The  first  task  class  member  function,  vary  requires  five  arguments.  The  first  is  the  address  of  the  variable 
being  varied,  the  second  is  an  expression  of  the  starting  value  for  this  variable,  the  third  and  fourth  arc  expres¬ 
sions  for  the  lower  and  upper  bounds  between  which  the  variable  will  be  constrained  to  lie.  Initially,  die  vari¬ 
able  should  be  between  these  bounds.  The  fifth  argument  is  the  address  of  the  specific  task  instance  that  this 
variable  is  associated  with. 

The  second  member  function,  cons  is  used  to  define  algebraic  constraints  or  equations  that  need  to  be 
solved.  This  function  requires  three  arguments.  The  first  is  used  only  to  reference  the  constraint  and  is  the 
address  of  any  variable  that  remains  in  existence  during  the  life  of  the  task’s  controlling  loop  and  that  is  not 
used  within  any  other  cons  function  call.  Typically,  one  would  use  the  address  of  one  of  the  variables  being 
varied  within  a  vary  call.  If  necessary,  one  could  define  a  dummy  variable  and  use  that  for  this  first  argument. 
Note,  it  need  not  have  a  value  or  even  any  meaning  for  the  problem.  Its  only  purpose  is  so  that  each  time  the 
cons  function  is  called  this  variable  can  be  checked  to  sec  what  constraint  is  being  defined.  The  second  argu¬ 
ment  is  an  expression  representing  the  equation  to  be  solved.  At  the  solution  this  expression  should  become 
zero  (to  within  a  specified  accuracy).  The  third  argument  is  the  same  as  with  the  vary  function  and  is  used  to 
refer  to  a  specific  task  that  this  nstiaint  is  associated  with. 

The  next  member  function  icons  is  exactly  as  the  cons  function,  but  is  used  to  define  inequality  con¬ 
straints.  This  function  would  only  be  used  when  one  is  defining  an  optimization  problem.  Here,  the  second 
argument  at  the  solution  will  be  constrainted  to  be  greater  than  or  equal  to  zero. 

The  mini  function  is  used  to  define  objection  functions  for  optimization  problems.  It  requires  two  argu¬ 
ments,  the  second  of  which  again  refers  to  a  specific  task.  The  first  argument  is  an  expression  representing  die 
objective  function  for  the  optimization  task.  At  the  solution  this  first  argument  should  represent  a  local 
minimum  of  the  objective  function. 

The  last  member  function,  diff  is  used  to  define  ordinary  differential  equations  for  the  task.  If  this  func¬ 
tion  is  called,  then  cons,  icons,  and  mini  should  not  be  called  for  this  task.  It  requires  three  arguments,  the  last 
being  the  address  of  the  task  instance  as  with  the  other  functions.  The  first  argument  is  the  address  of  the 
dependent  variable  for  the  differential  equation  being  defined.  This  equation  is  of  the  form 

Thus,  the  first  argument  would  be  the  x  in  this  equation.  The  second  argument  is  the  expression  /.  As  noted 
above,  the  variable  t  is  represented  by  the  class  variable,  time. 

As  mentioned  previously,  these  task  class  functions  are  called  within  the  GPS  input  by  using  operators 
with  the  same  names,  that  is,  vary,  cons,  icons,  mini  and  diff.  In  this  case,  those  arguments  that  were  required 
as  addresses  arc  specified  as  literals  within  the  GPS  inputs.  In  addition  the  last  argument  to  each  function  is 
automatically  filled  in  by  the  GPS  coding.  These  functions  arc  also  sometimes  used  directly  within  some  of  die 
C  model  classes. 

There  arc  also  several  other  task  class  member  functions  vary!,  consl,  iconsl,  and  difll  which  arc  exactly 
like  those  described  above  except  that  a  character  string  rather  than  a  pointer  is  used  for  the  first  argument. 
These  functions  arc  used  only  within  the  GPS  code  itself.  Finally,  one  oilier  member  function  diffv  is  used  to 
assign  initial  values  to  any  variables  being  integrated.  This  function  is  also  only  used  within  die  GPS  code. 


15 


2.5.  Task  Class  Examples 

In  this  section  several  examples  are  presented  that  make  use  of  the  task  class.  The  examples  presented  should 
give  a  flavor  of  the  type  of  problems  that  can  be  set  up  and  solved  by  showing  how  to  solve  purely  mathemati¬ 
cal  problems,  such  as  solving  equations,  performing  optimizations,  and  solving  systems  of  differential  equations. 
These  basic  techniques  will  then  be  used  in  later  chapters  with  actual  spasms  models  to  form  and  solve  system 
constraints,  optimizations,  etc.  Appendix  A  shows  each  of  the  following  examples  with  their  resulting  output. 

2.5.1.  Example  one 

The  first  example  sets  up  a  purely  mathematical  problem  of  solving  a  single  equation  in  a  single  unknown.  The 
equation  is 

x2-e~x=0. 

Problems  such  as  this  are  solved  by  varying  the  value  of  x  iteratively  until  the  equation  is  satisfied.  Thus  there 
are  three  major  aspects  to  solving  (lie  problem.  First  some  iterative  loop  must  be  defined.  This  loop  will  be 
called  the  task  loop;  the  task,  in  this  ease,  is  to  solve  the  equation.  The  task  loop  will  need  to  control  the  itera¬ 
tions  and  to  terminate  when  the  task  is  solved.  The  second  aspect  is  to  define  what  variable  is  being  varied  to 
carry  out  this  task  and  to  define  a  starting  value  and  bounds  for  this  variable.  The  third  aspect  is  to  define  the 
equation  to  be  solved.  This  equation  will  also  be  called  the  constraint  for  the  task.  In  order  to  easily  specify 
each  of  these  aspects  some  simple  operators  have  been  created.  Thus,  in  order  to  specify  die  variable  to  be 
varied  the  vary  operator  is  used.  For  specifying  the  constraint  equation,  the  cons  operator  is  used.  For  defining 
task  control,  a  task  class  instance  is  allocated  using  cnew  and  some  GPS  loop  construct  (c.g.  the  while  operator) 
is  used  to  define  the  iterative  task  loop.  The  complete  GPS  input  necessary  to  solve  the  problem  is  as  follows. 

cinit 

[/task  /a]  cnew 
(a.c) 

(/x  1.0  0.0  2.0  vary 
/x  (x*x-cxp(-x))  cons 
} 

while 
/a  cdcl 

Here  the  cinit  operator  is  called  to  perform  any  model  class  initiation.  This  must  always  be  done  before  any 
other  reference  to  a  model  class,  including  the  task  class  is  made.  The  cnew  operator  is  then  used  to  define  the 
task  instance  denoted  as  a.  In  general,  the  task  controlling  function  is  given  by  the  task  member  function  named 
c.  Thus,  in  this  ease  the  task  controlling  function  would  be  referenced  within  the  GPS  input  as  a.c.  An  iterative 
while  loop  is  then  started  to  carry  out  the  computations  within  the  task.  In  this  case  the  task  controlling  func¬ 
tion  a.c  is  called  which  will  return  a  1  (true)  until  convergence  is  obtained,  thus  causing  the  second  procedure 
defining  the  varying  of  the  x  and  evaluation  of  the  constraint  equation  to  be  executed  iteratively.  When  conver¬ 
gence  has  been  obtained  the  a.c  function  v.  ill  return  a  0  and  the  while  loop  will  terminate.  As  indicated  previ¬ 
ously,  the  vary  operator  takes  the  name  of- the  variable  to  be  varied  specified  as  a  literal,  in  this  ease  /x,  fol¬ 
lowed  by  a  starting  value,  and  lower  and  upper  bounds,  here  taken  as  1.0,  0.0,  and  2.0,  respectively.  The  cons 
operator  takes  a  literal  (for  labeling  the  constraint),  here  specified  as  /x,  and  the  equation  residual.  The  last  line 
in  the  GPS  input  simply  deletes  the  task  a.  Note  that,  since  no  parameters  for  the  task  a  were  initialized  with 
the  cnew  operator,  the  default  value  for  the  task  printout  will  be  in  effect  and  thus,  the  default  level  (a.prt=2) 
print  out  for  this  problem  will  appear  on  the  standard  output  file. 

2.5.2.  Example  two 

The  second  example  extends  the  first  example  to  a  system  of  algebraic  equations  to  be  solved.  For  illustrations, 
suppose  these  equations  are 

(r-l)2-y=0 


y-21og(e*+l)=0 
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i2-x= 0. 

Here  the  GPS  input  would  again  consist  of  a  single  equation  solving  task  but  would  include  two  additional  vary 
and  cons  operators  to  define  the  two  additional  variables  to  be  varied  and  the  two  additional  equation  residuals. 
Thus,  the  input  is  as  follows. 

cinit 

[/task  /a]  cncw 
(a.c) 

{/x  2  (-20)  20  vary 
/y  2  (-20)  20  vary 
/z  2  (-20)  20  vary 
/x  (pow(x-l,2)-y)  cons 
/y  (y-2*log(cxp(x)+l))  cons 
/z  (z*z-x)  cons 
) 

while 

"\nx=%.2f  y=%.2f  z=%.2f"  [x  y  z]  printf 
/all  cdcl 

As  before  one  must  decide  on  some  reasonable  starting  values  for  x ,  y ,  and  z  and  on  the  upper  and  lower 
bounds  for  these  variables.  At  times  this  can  be  difficult  and  several  different  values  may  have  to  be  tried  in 
order  to  ultimately  find  a  solution.  This  is  especially  true  if  the  problem  at  hand  has  several  solutions  and  one  is 
seeking  a  particular  one.  In  that  ease  changing  the  bounds  may  be  used  to  force  the  equation  solver  to  search 
for  a  solution  within  a  particular  region.  In  this  ease,  for  lack  of  more  information,  the  starting  values  for  all 
three  unknowns  were  taken  as  2,  and  the  upper  and  lower  bounds  taken  as  20  and  -20,  respectively.  Addition¬ 
ally,  the  printf  operator  was  used  to  print  out  the  final  values  (however,  like  the  previous  example,  the  default 
print  out  each  iteration  will  also  appear). 

Since  the  task  a.acc  parameter  defining  the  termination  criteria  was  not  specified,  the  default  value  was 
used  stopping  the  iterations  when  the  square  root  of  the  sum  of  the  squares  of  the  equation  residuals  was  less 
then  lc-3.  This  occurred  on  the  5th  iteration  where  the  sqrt  of  the  sum  of  the  squares  of  the  residuals  was 
2.549055e-4.  If  additional  accuracy  is  required,  a.acc  should  be  made  smaller.  If  substantially  greater  accuracy 
is  required  then  for  more  difficult  problems  the  default  maximum  number  of  allowed  iterations,  currently  40, 
defined  by  a.maxit  will  probably  need  to  be  made  larger. 

2.5.3.  Example  three 

The  third  example  sets  up  precisely  the  same  problem  as  example  two  but  in  this  ease  splits  the  problem  into 
two  nested  equation  solving  tasks.  This  is  to  show  how  complex  problems  might  be  decomposed  into  simpler 
tasks  (although  this  example  is  easily  solved  as  a  single  task).  In  this  case,  after  calling  cinit,  two  class  task 
objects,  a  and  b,  arc  allocated  with  cnew,  one  for  each  of  the  two  equation  solving  tasks.  In  the  example,  z  will 
be  solved  for  within  the  inner  task  denoted  as  b  and  x  and  y  will  be  solved  for  within  die  outer  task  denoted  as 
a.  In  order  to  reduce  the  number  of  iterations  to  solve  the  problem,  z  is  given  the  initial  value  2  using  a  def 
operator  before  entering  the  task  loops.  In  this  way  z  can  be  iniu’alized  to  its  current  value  each  time  the  inner 
or  b  task  loop  is  started.  This  z  value  will  generally  be  better  than  simply  taking  z  with  some  fixed  starting 
value.  The  complete  input  would  be  as  follows. 

cinit 

[/task  /a  ]  cncw 
[/task  /b  ]  cncw 
/z  2.0  def 
[a.c) 

(/x  2.0  (-20)  20.0  vary 
/y  2.0  (-20)  20.0  vary 
(b.c) 

{/z  z  (-20)  20  vary 
/z  (z*z-x)  cons 
) 
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while 

/x  (pow(x-l,2)-y)  cons 
/y  (y-2*log(cxp(x)+l))  cons 
) 

while 

,'\nx=%.2f  y=%.2f  z=%.2f'  [x  y  z]  printf 
/all  cdel 

As  can  be  seen  by  the  input,  the  only  change  compared  to  example  two  is  the  nesting  of  the  inner  task  while 
loop  to  solve  the  equation  in  z  within  the  procedure  used  to  solve  for  x  and  y.  Decomposing  a  problem  into 
nested  problems  such  as  this  is  often  an  effective  means  of  solving  a  problem  that  seems  to  be  intractable  using 
only  one  task.  Note,  that  if  such  a  nesting  is  done,  it  often  helps  to  keep  the  tolerance  within  the  inner  loops 
tighter  than  the  outer  loops.  This  is  to  prevent  the  inner  iterations  from  washing  out  the  effects  of  small  pertur¬ 
bations  of  the  outer  loop  variables  when  gradients  of  the  constraints  are  being  calculated. 

2.5.4.  Example  four 

As  a  fourth  example  we  show  how  a  nonlinear  constrained  optimization  problem  can  be  solved.  The  problem  for 
illustrations  is  as  follows, 

min  (x-l)2+(y-2)2+re* 
such  that  x-y=0 
x-z> 0 

and  where  all  of  the  variables  lie  within  0  to  10. 

Again  a  single  task  class  can  be  used  to  solve  the  problem,  in  this  case,  using  the  icons  and  mini  opera¬ 
tors.  The  complete  input  to  solve  the  problem  is  as  follows. 

cinit 

[/task  /a]  cnew 
{ac} 

{/x  1  0  10  vary 
/y  2  0  10  vary 
/z  3  0  10  vary 
/x  (x-y)  cons 
/y  (x-z)  icons 

((x-l)*(x-l)+(y-2)*(y-2)+z*exp(z))  mini 

) 

while 

'\nx=%.2f  y=%.2f  ■/.=%. 2  f  [x  yz]  printf 
/all  cdel 

Here,  the  starting  values  where  taken  as  1,  2,  and  3  for  the  three  variables.  Like  the  cons  operator,  the  icons 
operator  takes  a  literal  (used  only  to  label  or  delimit  this  constraint  from  others)  and  the  constraint  residual.  For 
inequality  constraints  this  residual  should  be  written  such  that  it  is  greater  than  or  equal  to  zero.  Inequality  con¬ 
straints,  of  course,  will  not  necessarily  be  zero  at  the  solution,  although  they  might  be.  For  such  optimization 
problems  more  inequality  constraints  can  be  imposed  than  the  dimension  of  the  problem.  The  mini  operator  is 
used  to  inform  the  optimizer  what  the  objective  function  to  be  minimized  is.  Optimization  problems  are 
inherently  more  difficult  to  solve  than  purely  equation  solving  problems;  thus,  at  times  one  may  need  to  redo  the 
problem  with  different  starting  points  and  adjustments  in  some  of  the  parameters  used  by  the  optimizer. 

As  with  tiie  decomposition  used  in  the  third  example,  additional  nested  tastes  defining  other  optimizations 
or  equation  solvings  can  be  included  to  define  arbitrary  problem  types. 

Although  this  problem  is  relatively  easy  to  solve,  with  the  final  solution  being  obtained  in  ten  iterations, 
this  certainly  is  not  always  the  case,  and  several  points  about  optimization  problems  should  be  mentioned.  First, 
such  problems  arc  considerably  more  difficult  to  solve  than  just  solving  algebraic  equations.  One  cannot  just 
look  at  the  potential  solution  and  "see"  that  it  is  the  solution.  This  is  because,  looking  at  the  residual  to  die 
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constraint  equations  and  noting  that  the  equality  and  inequality  constraints  arc  satisfied  is  only  part  of  what 
needs  to  be  considered.  At  the  solution  the  Kuhn-Tuckcr  conditions  should  hold.  These  conditions  can  only  be 
evaluated  by  knowning  the  Lagrangian  multipliers  and  gradients  of  the  objective  functions  and  constraints. 
Secondly,  during  the  iterations  it  is  quite  possible  that  the  value  of  the  objective  function  may  need  to  increase, 
for  example,  when  one  needs  to  go  "uphill"  in  order  to  satisfy  the  constraints.  Thirdly,  iterative  techniques  like 
the  one  being  used  here,  generally  only  find  local  minimums.  To  find  a  global  minimum  often  requires  substan¬ 
tially  more  work  and  sometimes  requires  apriori  estimates  of  the  second  derivatives  of  the  objective  functions 
and  constraints.  These  often  are  not  available.  Fourthly,  the  problem  posed  may  not  even  have  a  local  solution. 
This  may  occur,  for  example,  when  no  feasible  region  exists  for  all  of  the  inequality  constraints  taken  together. 

With  these  and  other  potential  problems  there  are  several  termination  messages  that  may  occur  when 
defining  optimization  tasks.  The  main  ones  arc  "initial  line  search  gradient  positive",  "convergence  of  indepen¬ 
dent  variables",  and  "more  than  5  function  calls  in  line  search".  Some  of  these  may  indicate  that  the  solution 
was  not  found,  while  in  other  eases,  they  may  signify  that  the  solution  was  found  but  not  to  die  level  of  accu¬ 
racy  requested.  In  some  eases  rerunning  the  problem  from  a  different  starting  point  can  sometimes  resolve  die 
difficulty.  At  other  dmes  diis  may  be  die  best  that  can  be  done  with  the  finite  differencing  used  in  calculaung 
the  gradients.  Sometimes  a  smaller  (or  even  larger)  value  of  del  might  be  tried.  Finally,  one  may  have  to 
decompose  the  problem,  for  example  putdng  th :  equality  constraints  within  an  inner  nested  task  or  even  resort¬ 
ing  to  parameter  sweeps  rather  than  an  opdmizadon  task.  Sometimes  parameter  sweeps  will  give  greater  insight 
into  the  problem  under  consideration  and  will  indicate  that  some  variables  might  be  eliminated  from  die  optimi¬ 
zation  problem,  thus,  reducing  the  dimensionality  of  the  problem. 

2.5.5.  Example  five 

As  a  fifth  example  we  set  up  an  integradon  of  three  differential  equadons. 


dt  2 


Again  cinit  and  cnew  are  used  to  define  a  task  denoted  as  a.  The  default  print  out  defined  by  die  prt  variable 
for  the  task  is  also  set  to  0  so  that  no  print  out  will  be  generated.  In  order  to  generate  several  intermediate  out¬ 
put  values,  a  sweep  is  made  on  the  variable  defining  the  output  dmes,  denoted  as  a.tout,  using  a  for  operator. 
Since  the  for  operator  pushes  onto  the  stack  the  current  iteradvc  value,  the  first  thing  done  within  die  procedure 
is  to  use  that  value  to  redefine  the  current  output  value.  Nested  within  this  for  loop  is  the  task  loop  implemented 
using  the  while  operator  as  before.  Within  die  procedure  of  the  while  operator  the  three  differential  equations 
arc  defined  using  the  vary  operator  to  indicate  the  variables  being  integrated  and  to  give  these  variables  starting 
values  and  the  diff  operator  for  specifying  the  right  hand  side  of  die  differential  equadons.  After  the  while 
operator  the  printf  operator  is  used  to  print  out  the  values  of  the  dmc,  and  the  three  variables.  The  complete 
input  is  as  follows. 

cinit 

[/task  /a  /prt  0]  cnew 

1.0  1.0  5.0 
{/a.tout  cxch  def 
(a.c) 

(/x  1.0  vary  /y  2.0  vary  /z  0.0  vary 
/x  (-x)  diff 
/y  (0.5*y)  diff 
/z  (x-y)  diff 
) 

while 

l'Vmimc=%.2f  x=%.3c  y=%.3 e  z=%.3e"  [a.time  x  y  z]  printf 

} 
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for 

/all  cdcl 

Unlike  the  arbitrary  nesting  of  equation  solving  and  optimization  tasks,  differential  equation  solving  tasks 
cannot  be  nested  within  each  other.  However,  differential  equation  solving  can  be  nested  within  or  outside  of 
equation  solving  or  optimization  tasks. 

2.5.6.  Example  six 

In  this  example,  we  consider  the  use  of  die  sintrp  operator.  As  described  within  the  previous  chapter,  this 
operator  signals  an  interrupt  just  as  if  the  user  had  typed  a  Control-c  at  the  keyboard.  By  using  sintrp  within  the 
GPS  input,  die  interrupt  can  be  made  to  occur  at  exactly  the  right  instance  during  the  computations.  Consider 
an  example  similar  to  the  previous,  only  now  let  us  suppose  that  after  a  predefined  time,  denoted  as  "trap"  in  the 
following,  we  want  the  integradons  to  stop  and  to  go  into  the  interrupt  mode.  In  order  to  add,  at  least,  one  other 
parameter  to  die  differential  equations,  the  equations  have  been  changed  slightly  with  the  parameter  "p"  intro¬ 
duced  into  the  first  equation.  Initially  "p"  takes  the  value  one  and  the  first  time  trap  is  taken  as  one  second. 
The  inputs  to  accomplish  this  are  as  follows. 

cinit 

[/task  /a  /prt  0]  cncw 

/intcrup  ("\ntime=%c"  [a.time]  printf  sintrp)  def 
/trap  1.0  def 
/p  1.0  def 
1.0  1.0  10.0 
(/a.tout  cxch  def 
(a.c) 

{(a.statc<=2  &&  a.time>=trap)  {intcrup)  if 
/x  1.0  vary  /y  2.0  vary  /z  1.0  vary 
/x  (-x*p)  diff 
/y  (0.5*y)  diff 
/z  (x-y)  diff 
) 

while 

"\ntime=%.2f  x=%.3e  y=%.3e  z=%.3e"  [a.time  x  y  z]  printf 

) 

for 

/all  cdcl 

Here,  as  with  example  five  the  iterative  task  loop  is  set  up  defining  the  equations  to  be  integrated,  only 
now  die  first  statement  within  that  loop 

(a.statc<=2  &&  a.Ume>=trap)  {intcrup)  if 

checks  if  the  integradon  state  is  less  than  or  equal  2  (see  the  discussion  of  the  state  variable  in  the  task  class) 
and  also  checks  to  see  if  the  time  is  greater  than  or  equal  to  the  trap  value.  If  these  conditions  arc  true  then  the 
procedure  "intenip"  is  called.  Here  "intcrup"  was  defined  prior  to  entering  the  task  loop  to  first  print  out  the 
current  time  and  then  execute  the  sintrp  operator.  At  that  point,  the  GPS  interrupt  mode  will  become  active  and 
prompt  for  input  at  the  terminal.  Such  input  might  simply  be  something  such  as 

gps_int>  x  =  y  =  p  = 

which  would  print  out  die  values  of  x,  y,  and  p.  One  might  also  redefine  p  to  have  a  new  value,  such  as 
gps_int>  /p  1.1  def 

One  must,  however,  before  resuming,  redefine  the  value  of  trap  to  be  some  later  time,  else  on  the  very  next 
iteration,  the  integradons  will  again  immediately  go  back  into  interrupt  mode.  Thus,  to  resume  the  integradons 
and  say,  stop  at  Ume  greater  than  or  equal  to  8.2,  one  would  input 

gps_int>  /trap  8.2  def  resume 

When  time  becomes  at  least  equal  to  8.2  again  the  interrupt  mode  would  be  entered  and  variables  can  be 
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queried  and/or  changed  as  before.  Note,  that  for  this  problem  it  would  not  make  sense  to  change  either  x,  y,  or 
z,  since  they  are  the  dependent  variables  of  the  problem.  Also,  as  this  problem  indicates,  some  thought  as  to 
when  the  interrupt  is  to  occur  is  usually  required.  In  this  case,  it  only  makes  sense  when  the  integrator  is  in  a 
state  with  a.state  less  than  or  equal  to  2. 

When  running  a  problem  such  as  this,  it  is  also  possible  to  interrupt  it  from  the  keyboard  with  a  control-c. 
In  that  case,  variables  can  be  queried,  but  the  integrator  state  might  not  be  appropriate  for  changing  even  an 
independent  variable,  such  as  the  p  variable  in  this  problem.  For  instance,  if  p  were  changed  while  the  integra¬ 
tor  was  trying  to  calculate  the  Jacobian  of  the  right  hand  side  of  the  equations,  a  bad  Jacobian  would  result,  pos¬ 
sibly  preventing  the  integrator  from  working.  Thus,  when  problems  are  constructed  to  be  interrupted  at  the  key¬ 
board,  it  is  probably  best  to  only  adjust  parameters  within  procedures  that  arc  called  at  appropriate  times  after 
the  interruption  is  resumed. 


CHAPTER  3 


Steady-State  Power  System  Model  Classes 


3.1.  Introduction 

In  this  section  wc  discuss  the  details  of  the  component  models  that  arc  used  to  analysis  a  steady-state  power  sys' 
tern.  These  models  consist  of  the  following. 


gas  - 

gas  flow  initiator 

sp  - 

gas  flow  splitter 

mx  - 

gas  flow  mixer 

In¬ 

gas  flow  heater/cooler 

fix  - 

gas  flow  heat  exchanger 

cp- 

compressor 

gt- 

gas  turbine 

pump  - 

pump 

df- 

diffuser 

nz  - 

nozzle 

power  - 

calculate  system  powers 

Each  of  these  model  classes  have  various  parameters  and  member  functions.  For  example,  the  hx  model  class 
has  c  and  h  functions  to  perform  the  calculations  on  the  cold  and  hot  sides  of  the  heat  exchanger.  In  general 
each  model  has  several  member  functions,  which  in  the  following  will  be  referred  to  by  the  suffix  name  only. 
Thus,  the  above  hx  class  c  function  is  actually  encoded  in  C  as  the  hxcO  function.  As  discussed  in  the  chapter 
on  model  and  utility  classes  each  of  the  models  has  a  allocator  function  denoted  by  the  suffix,  new,  requiring  a 
character  string  as  an  argument  This  character  string  will  be  used  for  referencing  the  model  instance  in  any 
printout  of  the  model’s  flows  or  parameters.  The  allocator  function  will  also  assign  default  values  to  any  input 
parameters. 

3.2.  Steady-State  Model  Flow  classes 

Before  discussing  the  model  classes  within  the  next  section,  some  understanding  of  the  flow  classes  required  by 
these  models  is  necessary.  As  indicated  previously,  the  flow  classes  represent  the  information  which  passes 
between  the  different  models.  These  classes  will  usually  represent  the  variables  describing  real  physical  fluids, 
but  can  also  represent  most  anything  the  modeler  desires.  In  general,  the  user  will  manipulate  the  flows  of  a  sys¬ 
tem  by  calling  the  models.  In  particular,  for  each  flow  class  there  is  a  special  model  that  is  used  to  initialize  the 
flow  and  to  save  and  restore  the  flow  to  a  flow  stack.  This  flow  stack  is  unique  for  each  flow  class.  Practically 
all  of  die  models  have  as  part  of  their  class  structure  one  or  more  instances  of  the  flow  classes.  These  arc  used 
to  store  the  values  of  the  flows  at  the  exit  of  the  model  and  can  be  used  in  forming  constraints  and/or  objective 
functions  within  the  GPS  input. 

The  present  list  of  steady-state  models  makes  use  of  only  one  flow  class,  that  of  gastype  for  representing 
fluids  and  has  the  following  variables. 

id  -  pointer  to  the  flow’s  id 

l  -  flow’s  temperature  in  K 

p  -  flow’s  pressure  in  atm 
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h- 

flow’s  enthalpy  in  J/kg 

s  - 

flow’s  entropy  in  J/kg-K 

r  - 

flow’s  density  in  kg/m3 

q- 

flow’s  quality 

m  - 

flow’s  mass  flow  rate  in  kg/s 

v  - 

flow’s  velocity  in  m/s 

atoms  - 

flow’s  atom  fractions 

comp  - 

flow’s  species  mole  fracdons 

Normally,  the  values  of  id,  t,  p,  h,  i,  r,  q,  m,  and  v  will  be  the  only  variables  that  a  user  is  likely  to  use.  There 
arc  actually  several  different  thermodynamic  property  codes  available  within  the  system.  The  actual  procedure 
that  is  used  to  determine  die  properties  is  determined  by  the  flow’s  identification  pointer,  id.  11ns  variable 
should  be  assigned  a  character  suing  of  the  type  "GAS"  or  "THR-specics",  where  species  is  one  of  the  several 
hundred  species  found  in  the  THRDATA  file.  In  the  case  where  the  pointer  is  to  "GAS"  the  actual  gas  is 
further  determined  by  die  contents  of  the  comp  array.  This  array  is  dimensioned  by  the  number  of  gas  species 
defined  in  the  prop.h  file.  For  convenience,  the  species  names  (in  caps)  arc  defined  as  a  sequence  of  integers  so 
that  the  user  can  refer  to  a  particular  species  by  referencing  its  name.  For  example,  the  C02  mole  fraction 
would  be  referenced  as  comp#C02.  (Note  that  the  usually  way  of  referencing  this  array  element  in  the  C 
language  would  be  comp[C02],  however,  the  "{]"  delimiters  in  GPS  would  define  a  GPS  array  rather  than  an 
element  of  the  comp  array.  Thus,  the  usual  way  of  referencing  a  C  array  element  in  GPS  is  by  suffixing  the 
array  name  with  a  "#’’  sign  and  then  the  element  number.  Note,  however,  that  this  referencing  is  actually 
defined  not  by  the  GPS  code  but,  by  the  ref  function  to  the  class,  and  thus,  could  lie  changed  by  the  user,  if 
desired.) 

In  addition  to  the  variables  the  gastype  class  has  several  member  functions.  These  arc  generally  only  used 
within  the  model  classes  and  thus,  really  don’t  need  to  be  of  any  concern  to  the  casual  user,  however  they  would 
be  of  concern  to  a  model  developer.  Prop  is  the  general  property  calculational  procedure.  For  any  instance  of 
this  gastype  class,  prop  can  be  called  to  determine  the  thermodynamic  properties  of  the  flow  either  as  a  function 
of  p  and  t,  p  and  h,  or  p  and  s  by  using  as  its  second  argument  the  letter ’t’,  ’h\  or  ’s’,  respectively.  Prop’s  first 
argument  is  the  address  of  the  flow. 

Another  member  function,  sat  is  used  to  determine  the  saturation  properties  of  the  flow  at  die  flow’s  pres¬ 
sure.  This  function  only  returns  values  for  flows  with  the  "THR-spccics"  id  as  the  "GAS"  flows  are  not  conden¬ 
sible.  If  called  with  a  "GAS"  flow  an  error  message  is  displayed  and  the  run  is  terminated.  Sal  requires  four 
arguments,  the  first  is  the  address  of  the  flow  and  the  rest  are  double  precision  variables  representing  the 
returned  values  of  critical  pressure  (atm),  and  the  saturation  liquid  enthalpy  and  vapor  enthalpy  (J/kg). 

The  atom  member  function  is  only  needed  for  flows  with  "GAS"  as  the  id  and  is  used  to  calculate  die  kg- 
atom/kg  of  the  individual  atoms  making  up  the  flow.  This  function  requires  one  argument  of  the  flow’s  address 
and  uses  the  flow’s  comp  array  to  determine  the  values  of  die  flow’s  atoms  array.  Note  that  it  is  the  atoms  array 
that  actually  determines  die  chemical  make  up  of  the  flow.  This  array  remains  constant  until  the  flow  either  has 
new  species  added  to  it  or  removed  from  it.  The  flow's  comp  array,  on  the  other  hand,  will  change  ju^t  like  the 
flow’s  temperature  or  pressure  and  reflects  only  die  current  equilibrium  species  mole  fractions. 

One  additional  function  is  provided  for  use  with  the  gastype  class  which  is  gasget  and  returns  the  next 
flow  from  the  gass. 

The  special  initializing  model  for  this  gastype  flow  is  denoted  as  gas  and  will  be  described  below.  The 
unique  stack  for  this  flow  is  denoted  as  gass.  The  gass  stack  itself  has  several  variables  and  two  member  print 
functions.  These  variables  are  as  follows. 

prl  -  print  flag  (0).  Input.  Prt,  when  set  to  one,  is  used  to  print  out  values  of  die  flow  each  lime  die 

properties  code  is  called.  Its  use  is  really  for  debugging. 

thrfsat  -  flag  (1).  Input.  Tlufsat,  when  set  to  one,  will  cause  the  THR  properties  code  to  first  produce  a 

tabic  of  the  saluradon  temperatures  as  a  function  of  die  pressure.  This  table  is  then  used  to 
calculate  the  saturation  temperature  whenever  it  is  needed  by  die  THR  properties  routines. 
This  is  only  a  performance  issue  to  eliminate  the  iterations  needed  to  calculate  the  saturation 
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temperature  later  on.  Note,  however,  these  iterations  must  be  done  initially  to  generate  the 
table. 

quit  -  count  of  errors  occurring  within  the  property  codcs(5).  Input.  Quit  is  initialized  to  five  and 

decremented  on  an  error.  When  zero  is  reached  it  is  assumed  that  the  run  is  having  too  much 
difficulty  and  is  terminated. 

The  two  gass  stack  functions  arc  the  print  function,  which  is  used  to  print  out  tables  of  the  flows’  state  vari¬ 
ables,  and  the  printc  function,  which  is  used  to  print  out  tables  of  the  flows’  species  concentrations.  Printc 
should  only  be  used  when  one  or  more  of  the  flows  have  the  "GAS"  flow  id. 

3.3.  Steady-state  models 

The  present  collection  of  steady-state  models  do  not  have  a  lot  of  process  related  details  but  represent  a  thermo¬ 
dynamic  description  of  the  model’s  phenomena.  This  is  basically  the  result  of  trying  to  keep  a  generic  quality 
to  the  supplied  models.  New  models  with  as  much  process  detail  as  is  required  can  be  added  by  the  user  as  will 
be  discussed  in  a  later  chapter. 

3.3.1.  Gas  (gas)  model 

The  gas  model  is  used  to  initiate  a  gas  flow  as  well  as  providing  member  functions  for  performing  the  saving 
and  restoring  of  flows  for  representing  complex  system  configurations.  The  member  function  used  to  initiate  a 
gastype  flow  is  denoted  as  c.  c  requires  no  input  flows  and  will  generate  one  output  flow  put  onto  the  gass 
stack.  The  modeling  begins  by  simply  assigning  values  to  the  flow  variables  as  follows. 

id=id!n 


m=min 


v=v;. 


P  "Pin 


compi-compi^  i=l  NS 

where  id  is  die  flow  id  as  discussed  above,  m ,  v ,  and  p  are  the  flow’s  mass  flow  rate,  velocity,  and  pressure, 
respectively,  comp ,  is  the  flow’s  i-th  species  mole  fraction  and  NS  is  the  total  number  of  species.  The  subscript 
in  represents  input  values.  Note,  that  NS  is  fixed  by  the  property  calculations  procedures  and  is  thus,  not 
directly  input. 

The  gastype’s  atom  function  is  then  called  to  determine  the  contents  of  the  flows  atom  array.  Note,  that 
the  assigning  of  species  to  the  comp  array  and  calling  the  atom  function  is  really  only  needed  for  flows  with  the 
id  of  "GAS”, 

Next  if  the  input  value  of  temperature  tin  is  specified  as  zero,  then  the  sat  property  function  is  called  to 
determine  the  saturation  liquid  and  vapor  enthalpies,  hi  and  ht.  The  flow’s  enthalpy,  h  is  then  determined  from 

h=h,+q(hg-h,) 

where  q  is  an  input  value  for  the  flow’s  quality.  If  the  temperature,  t,n  is  non-zero,  then  the  flow’s  temperature 
is  simply  assigned  this  input  value 

t=Un 

and  die  prop  function  is  then  called  to  determine  the  flow’s  enthalpy.  In  either  ease,  the  prop  function  is  again 
called  with  enthalpy  as  the  input  to  determine  the  flow’s  density,  entropy,  etc. 

The  parameters  to  the  model  are  as  follows.  The  default  values  of  the  parameters  are  specified  in 
parenthesis  and  an  indicadon  of  whether  the  parameter  is  an  input  is  also  given. 

id  -  gas  flow  id  ("THR-tH2").  Input. 

flow  rate  (1.0  kg/s).  Input. 


m  - 
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v  -  flow  velocity  (10.0  ni/s).  Input. 

p  -  flow  pressure  (1.0  atm).  Input. 

t  -  flow  temperature  (298.16  K).  Input. 

q  -  flow  quality  (0.0).  Input. 

comp#i  -  mole  fraction  of  the  i-th  species.  Input. 

dp  -  difference  in  pressure  between  the  flow  entering  the  cycl  function  (see  below)  that  dial  leaving 

the  c  function. 

dt  -  similar  to  the  dp  variable  but  for  temperature, 

dh  -  similar  to  die  dp  variable  but  for  enthalpy, 

dm  -  similar  to  the  dp  variable  but  for  mass  flow  rate, 

dv  -  similar  to  the  dp  variable  but  for  velocity. 

11  -  exit  flow  structure  from  the  model.  Note  that  fl  needs  to  be  further  qualified  with  one  of  the 

gastype  parameters,  such  as,  "fl.t". 

As  noted  above  if  the  temperature  is  specified  as  zero  then  the  model  assumes  that  the  flow  is  to  start  at  the 
saturation  temperature  corresponding  to  the  input  pressure.  In  this  ease  the  specified  flow  quality  is  used  to 
determine  the  inlet  enthalpy.  Thus,  quality  set  to  zero  refers  to  the  liquid  saturation  line  and  set  to  one,  the 
vapor  saturation  line. 

The  member  function  used  to  save  a  flow,  that  is  remove  a  flow  from  the  gass  stack,  is  denoted  as  sav. 
When  a  gas  model  instance  is  defined  for  use  in  saving  (and  recovering)  a  flow  it  will  never  be  used  in  any 
printout.  Also  no  input  model  parameters  need  to  be  specified. 

The  member  function  for  recovering  a  saved  flow  is  denoted  as  rec. 

An  addition  member  function  denoted  as  cycl  is  also  provided.  This  function  requires  one  input  flow  from 
die  gass  stack  and  calculates  the  differences  in  temperature,  pressure,  enthalpy,  mass  flow,  and  velocity,  denoted 
respectively  by  dt,  dp,  dh,  dm,  and  dv,  between  this  input  flow  and  the  output  flow  from  the  corresponding  c 
function.  This  function  is  provided  to  help  set  up  the  system  constraints  on  a  flow  path  that  forms  a  dosed 
cycle.  In  addition,  this  function  will  calculate  the  difference  in  power  (mass*cnthalpy)  between  these  two  flows 
and  save  this  in  the  variable  powcr.hcat  Note  that  for  a  correctly  formulated  closed  path,  this  variable  should  be 
zero. 

3.3.2.  Mixer  (mx)  model 

The  mixer  model  is  used  to  mix  together  two  gastype  flows  using  the  member  function  c.  This  function  requires 
one  input  flow  to  be  on  the  gass  stack  and  puls  one  output  flow  back  onto  the  stack.  The  other  input  flow  is 
obtained  by  calling  another  member  function,  s.  This  function,  which  must  be  called  before  the  c  function, 
requires  one  input  flow  on  the  gass  stack  but  generates  no  output  flows.  The  model  requires  no  input  parame¬ 
ters.  Unlike  die  other  models,  since  all  the  output  is  available  widiin  the  gas  flow  outputs  no  print  member 
function  is  used. 

The  modeling  widiin  the  mixer  is  dependent  on  whether  or  not  die  input  flows  arc  "GAS”  flows.  For  such 
flows,  the  output  comp  array  of  species  mole  fractions  mustbe  first  calculated.  This  is  done  as  follows. 

mwf^mWj  compu 
/mv2=Xmvv,  comp  2 j 
melij^cnmpij  m-Jmwx  >=1  ■  ■  ■  NS 
mol 2, -comp  2i  >n2lmw2  i= 1  •  •  ■  NS 
mol^moly+molij  /=!■••  NS 
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compi=mi  l^ntj  i=l  •  •  •  NS 

where  inoli ,  compt ,  m ,  »w,- ,  and  mw  arc  the  molar  flow  rate  array,  flow  mole  fraction  array,  flow  mass  flow 
rate,  species  molecular  weight  array,  and  flow  molecular  weight,  respectively,  and  the  subscripts  1  and  2 
correspond  to  the  two  input  flows.  Once  the  mole  fractions  compi  of  the  output  flow  arc  known,  the  atom  func¬ 
tion  is  dicn  called  to  determine  the  flow’s  atom  fraction  values. 

For  both  "GAS"  and  non-"GAS"  type  flows  the  following  calculations  arc  then  made  to  determine  the  out¬ 
put  flow’s  pressure,  enthalpy  and  mass  flow  rate. 

p=mm(p\4>d 

h  =(m  i  h  \+m  2h  2)  /  (m  i+m  2) 


m=m\+m2 

Finally,  the  prop  function  is  called  with  enthalpy  as  an  input  to  determine  the  flow’s  entropy,  density,  and  tem¬ 
perature.  At  present,  the  mixer  model  cannot  mix  together  flows  with  different  flow  id’s. 

The  only  output  parameter  for  the  model  is 

fl  -  representing  the  exit  gastype  flow  from  the  model.  As  with  all  model  flows,  fl  would  need  to 

be  further  qualified,  such  as  fl.t  when  used  within  the  GPS  input. 

3.3.3.  Splitter  (sp)  model 

The  splitter  model  is  used  to  split  a  gastype  flow  into  two  flows  using  the  member  function  c.  The  function 
requires  one  input  flow  on  the  gass  stack  and  will  put  one  output  flow  back  onto  the  stack.  The  second  output 
flow  can  be  obtained  by  calling  the  member  function  s.  This  function  requires  no  input  flows  and  should  only 
be  called  after  the  primary  function  c  is  called. 

The  modeling  done  within  the  splitter  is  dependent  on  whether  the  splitter  is  being  used  to  split  off  certain 
species  or  simply  split  the  whole  flow.  If  the  split  ratio  value,  sr,  is  zero,  then  it  is  assumed  that,  at  least,  one 
element  of  the  species  split  ratio  array,  ssrit  is  non-zero.  In  that  case  the  mass  flow  rates  of  each  species  must 
be  calculated  to  determine  the  split  off  flow.  This  is  done  as  follows. 

mwiH=Yjmwi  c°mpin,: 


mxi=ssri  compin%i  mw-,  min  / mwM 


m  1>t=(l -ssr;)compini  mwt  min  / mwin 

where  mwln  is  the  inlet  flow’s  molecular  weight,  m\j  and  m2j  are  the  individual  species  mass  flow  rates  of  flow 
1  and  2,  compin  is  the  inlet  flow’s  mole  fraction  array,  mw,  are  the  individual  species  molecular  weights  and  min 
is  the  inlet  flow’s  mass  flow  rate.  Once  the  individual  species  mass  flow  rates  are  known,  the  total  flow  rates  for 
the  two  flows  can  be  determined. 

mi =2>u 


'H2=2>2.; 

The  new  mole  fraction  arrays  for  each  flow  can  then  be  determined  as  follows. 
compij=m\j  /  mwt 


comp\j=comp\ti  I'Ecompi  j 


comp2j=m2j  /  mwi 


comp  x  =comp  2,;  /'%j:omp  2j 

The  atom  function  is  then  called  for  both  flows  to  determine  each  flow’s  atom  fraction  array  followed  by  a  call 
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to  the  prop  function  with  the  inict  temperature  as  input  to  determine  each  flow's  enthalpy,  entropy,  and  density. 
When  sr  is  non-zero,  the  above  calculations  arc  replaced  by  the  following. 
m2 =sr  m!n 


m{=min-m2 

In  this  case  there  is  no  need  to  call  the  prop  function  as  the  exit  flow’s  state  variables  arc  the  same  as  the  inlet 
flow’s. 

The  model’s  parameters  arc  as  follows. 

sr  -  split  ratio  representing  the  fraction  of  input  mass  flow  rate  that  is 

output  flow  (0.5).  Input. 

ssrlti  -  i-lh  species  split  ratio  representing  the  fraction  of  the  input  mass 

that  is  split  off  to  form  the  second  output  flow.  Input. 

fl  -  primary  flow  structure  from  the  model.  Output. 

112  -  secondary  or  split-off  flow  from  the  model.  Output. 

The  ssr  array  may  only  be  used  with  flows  having  the  "GAS"  id  and  is  used  only  when  the  sr  parameter  is  set  to 
zero.  Since  both  sr  and  ssr  represent  fractions  of  the  input  flow  mass,  their  values  should  be  between  0  and  1. 
The  ssr  array  elements  should  not  be  all  zeros  or  ones,  as  this  would  make  one  of  the  output  flows  have  a  zero 
mass.  Note  thai  since  the  sr  variable  is  by  default  not  zero,  if  ssr  is  to  be  used  sr  must  be  explicitly  set  to  zero. 

3.3.4.  Heater  (ht)  model 

The  heater  model  is  used  to  transfer  heat  into  or  out  of  a  gastype  flow.  The  model  has  one  main  calculation 
function  c.  The  function  takes  one  input  flow  from  the  gass  stack  and  puts  one  output  flow  back  onto  the  stack. 

The  model  first  calculates  the  exit  flow  pressure  p  based  on  an  input  pressure  fraction  fp  as  follows. 

P  ~Pin  fp  Pin 

where  pin  is  the  inlet  flow  pressure.  The  model  then  calculates  the  enthalpy  change  based  on  one  of  three 
options.  If  the  exit  flow  temperature  t  is  specified  as  non-zero,  then  the  exit  flow  enthalpy  is  simply  calculated 
from  the  prop  function  using  t  as  input.  If  t  is  zero,  then  the  model  checks  the  exit  flow  quality,  q  and  if  that 
variable  is  greater  than  -100  then  the  sat  function  is  used  to  determine  the  saturation  liquid  and  vapor  cndialpics, 
h,  and  hv  at  the  exit  flow  pressure.  These  values  are  then  used  to  calculate  the  exit  flow  enthalpy  from 

h=h,+q  (hv-h,). 

Finally,  if  q  is  not  greater  than  100,  the  heat  transferred,  Q  is  used  to  determine  the  exit  flow  enthalpy  from 
h=h;n+Qlm 

where  hm  is  the  inlet  flow  enthalpy  and  m  is  the  mass  flow  rate  through  the  heater.  Once  the  enthalpy  of  the 
flow  is  known,  the  prop  function  is  called  to  determine  the  temperature,  entropy,  and  density  of  the  exit  flow.  In 
addition,  the  heat  transferred  from  cither  the  input  or  from 

Q=(h-h!n)l  m 
is  stored  for  later  print  out 

The  parameters  to  the  model  are  as  follows, 
temp  -  temperature  of  the  exiting  gas  flow  (500  K).  Input, 

qua!  -  quality  of  the  exiting  gas  flcw(  1000).  Input, 

pfrac  -  fraction  of  the  input  pressure  used  as  a  pressure  drop  (0.0).  Input, 

heat  -  heat  input  (w).  Input, 

fl  -  exit  flow  from  the  model.  Output. 


split  off  to  form  the  second 
flow  rate  of  the  i-lh  species 
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Only  one  of  temp,  qual  or  heat  should  be  input.  Temp  is  used  if  not  equal  to  zero.  If  temp  is  zero,  then  qual  is 
used  if  greater  than  -100  (of  course,  if  it  is  input  it  should  be  something  reasonable).  In  this  case  the  exit  tem¬ 
perature  will  be  the  saturation  temperature  at  the  exit  pressure  if  qual  is  between  zero  and  one.  Note  that  qual 
can  be  set  less  than  zero  to  represent  subcoolcd  flow  or  greater  than  one  for  superheated  flow.  If  either  temp  or 
qual  is  used  to  determine  the  exit  flow  temperature,  then  heat  is  an  ou'n>it  variable.  Finally,  if  temp  or  qual  are 
not  used  (i.e  set  to  0.0  and  -1000,  respectively),  then  heat  is  used  directly  to  determine  the  exit  temperature. 
Note  that  heat  can  be  a  negative  number  in  which  case  this  model  will  act  like  a  flow  cooler. 

3.3.5.  Gas  turbine  (gt)  model 

The  gas  turbine  model  represents  a  simple  expansion  to  a  given  exit  pressure  at  a  given  efficiency.  The  model 
has  a  main  calculational  member  function  denoted  c.  This  function  requires  one  input  flow  from  gass  sutek  and 
puts  one  output  flow  back  onto  the  stack. 

On  entry  to  the  model,  the  exit  flow  pressure,  p  is  assigned  the  specified  input  value  p,u, 

P-Ptnf 

The  prop  function  is  then  used  with  the  inlet  flow  entropy  as  the  input  to  determine  the  enthalpy  hs  of  the  flow 
for  an  iscntropic  pressure  change  from  the  inlet  to  the  exit  The  exit  flow  enthalpy  h  is  then  determined  from 

h=h;n-T\(hin-hs) 

where  ii  is  the  specified  efficiency  and  hin  is  the  inlet  flow  enthalpy.  The  power  produced  is  then  calculated 
from 


Pow=m  (hM-h). 

Finally,  the  prop  function  is  called  with  enthalpy  as  the  input  to  determine  the  exit  flow  temperature,  entropy, 
and  density. 

The  model  has  the  following  parameters: 
pres  -  exit  flow  pressure  (1  atm).  Input, 

eff  -  efficiency  of  the  expansion  process  (0.85).  Input 

power. work  -  thermodynamic  work  generated  by  the  expansion  process.  Output, 

fl  -  exit  flow  from  the  model.  Output. 

3.3.6.  Gas  compressor  (cp)  model 

The  gas  compressor  model  represents  a  simple  compression  to  a  given  exit  pressure  at  a  given  efficiency.  The 
model  has  one  calculational  member  function  denoted  c.  This  function  requires  one  input  flow  from  die  gass 
stack  and  puts  one  output  flow  back  onto  the  stack.  The  compressor  model  is  very  similar  to  the  gas  turbine 
model  only  the  exit  flow  enthalpy  is  calculated  slightly  differently.  The  model  first  assigns  the  exit  flow  pres¬ 
sure  to  be  the  specified  exit  value. 

P=Ptx if- 

Thcn  the  prop  function  is  called  to  dcterminc  the  enthalpy  h,  of  the  iscntropic  compression  to  the  exit  pressure. 
The  exit  enthalpy  h  is  then  determined  from 

h=hin  +(h  - h;n ) / T| 

and  the  power  required  from 

Pow=m  (hin  -h) 

whcie  hin  is  the  inlet  flow  enthalpy,  m  is  the  mass  flow  rate,  and  n  is  the  specified  efficiency. 

The  model  has  the  following  parameters: 
pres  -  exit  flow  pressure  (5.0  atm).  Input, 

eff  -  efficiency  of  the  compression  process  (0.85).  Input. 
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powcr.work  -  thermodynamic  work  required  by  the  compression  process.  Output.  Note,  that  this  parameter 
is  treated  as  an  algebraic  quantity,  with  negative  values  indicating  work  consumed.  Thus,  in  a 
normal  compression  process  this  parameter  will  be  negative. 

fl  -  exit  flow  from  the  model.  Output. 

3.3.7.  Heat  exchanger  (hx)  model 

The  heat  exchanger  models  the  transfer  of  heat  from  a  hot  gastype  flow  to  a  cold  gastype  flow.  This  is  done 
using  two  member  functions  h  for  the  hot  side  and  c  for  the  cold  side  of  the  exchanger.  Both  of  these  member 
functions  require  one  input  flow  from  gass  stack  and  put  one  output  flow  back  onto  the  stack. 

The  model  has  several  options  and  makes  use  of  either  a  tcou  or  a  t^,  to  specify  the  exit  flow  temperature 
t  on  either  the  cold  or  hot  sides.  The  particular  variable  that  is  specified  should  refer  to  the  function  that  is 
called  first  within  the  GPS  inputs,  either  h  or  c.  Thus,  one  has  either 

t  =‘ccU 


Q=m  (h  -  /if*) 


or 


t=tho, 


Q=m  (7i;„  -h) 

where  h,„  in  the  inlet  flow  enthalpy  on  the  appropriate  hot  or  cold  side  and  the  exit  flow  enthalpy  h  is  deter¬ 
mined  from  a  call  to  the  prop  function  with  the  temperature  as  input.  Once  Q  is  known  it  is  used  on  the  other 
side  to  calculate  the  exit  flow  enthalpy,  which,  in  turn,  determines  the  other  exit  flow  stale  properties  using  a 
call  to  the  prop  function.  As  an  additional  option,  Q  can  be  input  directly  rather  than  one  of  the  exit  tempera¬ 
tures.  In  this  ease,  both  tcM  and  t^,  should  be  set  to  zero. 

Once  both  sides  of  the  heat  exchanger  have  been  called,  the  log  mean  temperature  difference  is  calculated 
using  stored  values  of  the  inlet  and  exit  temperatures, 

^num=(x-y)!\og(x/y) 

where  x  and  y  arc  the  inlet  and  exit  fluid  temperature  differences  of  the  heat  exchanger.  Note  that  for  the  pur¬ 
pose  of  using  A rTOan  in  system  constraints,  if  either  jt  or  y  or  both  become  less  than  zero,  a  fictitious  value  of 
A tmtm  is  returned,  although  one  that  still  shows  the  correct  trend  as  a  function  of  x  and  y .  Based  on  specified 
values  of  hot  and  cold  heal  transfer  coefficients,  u^,  and  an  overall  heat  transfer  coefficient  is  determined 
from 

1 

U  ■  . . 

and  the  heat  transfer  area  by 

A=QI(u  A /w„) 

The  model’s  input  parameters  arc  as  follows. 
t_cold  -  exit  temperature  (0.0  K)  of  the  cold  side. 

l_hot  -  exit  temperature  (0.0  K)  of  the  hot  side. 

heat  -  amount  of  heat  (0.0  watts)  transferred  from  the  hot  to  the  cold  flows, 

ufh  -  heat  transfer  film  coefficient  (1000  \vatts/m2K)  for  the  hot  side, 

ufc  -  heal  transfer  film  coefficient  (1000  watts/m2K)  for  the  cold  side. 

type  -  character  string  indicating  the  type  of  heat  exchanger,  "count"  for  counter  flow  or  "parol"  for 

parallel  flow  ("para!"). 

Only  one  of  t_cold,  t_hot,  or  heat  should  be  input  to  the  model.  If  either  t_cold  or  tjiot  is  used  then  that  side 
of  the  heat  exchanger  should  be  called  first.  These  parameters  arc  used  to  determine  the  value  of  heat  which 
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then  becomes  an  output  parameter.  If  both  t_co!d  and  t_hot  are  zero,  then  the  value  of  heat  is  used  directly  to 
determine  the  exit  conditions. 

The  main  outputs  from  the  model  arc 
lmtd  -  log  mean  temperature  difference  across  the  exchanger, 

area  -  heat  transfer  surface  area  (sq.  meters), 

fie  -  exit  cold  side  flow, 

flh  -  exit  hot  side  flow. 

Note  that  if  system  constraints  arc  to  be  placed  on  either  lmtd  or  area,  then  the  system  task  loop  should 
include  both  the  h  and  c  functions  for  this  model. 

3.3.8.  Pump  (pump)  model 

The  pump  model  represents  a  simple  liquid  flow  compression  process  to  a  specified  pressure  at  a  specified 
efficiency.  Note  that  this  model  assumes  that  the  liquid  is  almost  incompressible  (constant  density)  and  thus, 
should  only  be  called  where  the  flow  is  in  the  liquid  region.  The  model  has  one  calculational  member  function 
denoted  c.  This  function  requires  one  input  flow  from  the  gass  stack  and  puts  one  output  flow  back  onto  the 
stack. 

The  modeling  consists  of  the  following  equations. 

Pow=m  (pin-ptxi,)l( Pfl) 


h=hln-Pow  I  m 
P=P,Xil 

where  Pow  is  the  power  required,  pin  is  the  inlet  pressure,  ptxj,  is  the  specified  exit  pressure,  p  is  the  fluid  den¬ 
sity,  m  is  the  mass  flow  rate,  p  is  the  exit  flow  pressure,  h  is  the  exit  flow  enthalpy,  and  q  is  the  specified 
efficiency.  Once  the  exit  flow  pressure  and  enthalpy  arc  known  a  call  to  prop  with  enthalpy  as  the  input  deter¬ 
mines  the  exit  flow  temperature  and  entropy. 

The  model’s  parameters  arc  as  follows, 
pres  -  exit  flow  pressure  (20.0  atm).  Input, 

eff  -  efficiency  of  the  compression  process  (0.85).  Input. 

power. work  -  the  work  required  (watts)  to  accomplish  the  pumping  action.  Output  Like  the  compressor 

model,  work  consumed  in  the  compression  process  will  be  indicated  by  a  negative  value  of  this 
parameter. 

(1  -  exit  flow  from  the  model.  Output. 

3.3.9.  Diffuser  (df)  model 

The  diffuser  model  represents  a  gaseous  flow  diffuser.  This  model  and  the  nozzle  model  are  the  only  steady 
state  models  that  make  use  of  the  flow  velocity.  The  diffuser  model  has  one  calculational  member  function 
denoted  c.  The  model  requires  one  input  flow  from  the  gass  stack  and  puts  one  output  flow  back  onto  the  stack. 

On  entry  to  the  model  the  total  pressure  p,  of  the  flow  is  determined  by  iterating  on  the  pressure  at  con¬ 
stant  inlet  entropy  until  a  value  of  the  enthalpy  equal  to  the  total  inlet  enthalpy  h,  is  obtained,  where 

h,=h  +v2/2 

and  h  is  the  inlet  enthalpy  and  v  is  the  inlet  velocity.  Once  this  total  pressure  at  the  inlet  is  known,  the  exit 
values  for  the  velocity,  enthalpy  and  pressure  are  then  determined  from 

v=vtli, 


h=hin  -v2/ 2 
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P=Pin +  <]>,- Pi*)>  Pr,c 

where  the  subscript  in  corresponds  to  the  inlet  values  and  Prtc  is  the  pressure  recovery  coefficient.  Finally,  a 
call  to  prop  gives  the  exit  values  for  the  flow  temperature,  entropy,  and  density. 

The  model  parameters  are  as  follows, 
vel  -  exit  velocity  (10.0  m/s)  from  the  diffuser.  Input. 

prcs_rcc  -  pressure  recovery  coefficient  (0.5).  Input. 

11  -  exit  flow  from  the  model.  Output. 

3.3.10.  Nozzle  (nz)  model 

The  nozzle  model  represents  a  gaseous  flow  nozzle.  The  model  has  one  calculalional  member  function  c.  It 
requires  one  input  flow  and  generates  one  output  flow. 

The  model  makes  use  of  a  specified  exit  pressure  ptlt,  and  a  call  to  the  prop  function  with  the  inlet 
entropy  value  to  determine  the  enthalpy  h,  for  an  iscntropic  expansion  to  the  exit  pressure.  The  exit  flow  velo¬ 
city  is  then  determined  by 

v 

The  exit  flow  enthalpy  is  then  found  from 
h=hin+(v£-v2)l2 

and  the  rest  of  the  exit  flow’s  state  variables  arc  determined  by  a  call  to  prop  with  the  exit  enthalpy  as  input. 
For  use  as  output  variables  the  exit  Mach  number,  thrust  and  specific  impulse  arc  then  calculated  from 

Mach  =v  V  (tipl'dp  )j 
thrust  =mv  +pA 
impulse  =t hr ast  /  (9.8m ) 

where  m  is  the  mass  flow  rate,  A  is  the  exit  flow  area,  and  (dpldp  ),  is  calculated  via  finite  differencing. 

The  input  parameters  arc 

pres  -  exit  pressure  (0.5  atm)  of  the  nozzle, 

eff  -  efficiency  of  the  nozzle  (0.85). 

The  output  parameters  arc 

area  -  exit  flow  area  (m2)  from  the  nozzle, 

mach  -  exit  mach  number  form  the  nozzle, 

thrust  -  thrust  (nt)  generated  by  the  nozzle, 

impulse  -  specific  impulse  (s)  of  the  nozzle, 
fl  -  exit  flow  from  the  model. 

3.3.11.  Combustor  (cb)  model 

The  combustor  model  is  used  to  bum  a  fuel  with  an  oxidizing  gas  flow.  The  fuel  is  described  by  Uie  input 
parameters  of  the  model  while  the  oxidizing  flow  is  taken  from  the  gass  stack,  and  must  be  a  flow  with  a  "GAS" 
id.  The  mode)  has  one  calculational  member  function  denoted  as  c  which  takes  one  input  flow  from  the  stack 
and  puts  back  one  output  flow. 

On  entry  to  the  model  a  reference  gas  calculation  is  made  to  ultimately  determine  the  heat  of  formation  of 
the  fuel.  This  is  done  by  first  calculating  the  mass  flow  rate  of  oxygen  necessary  to  burn  the  fuel  at  a 
stiochiomctry  of  one  from 

m0  =(2.664 1  wc  +  7.93645  wh  +  0.99797  wt  -  w0 )  mlutl 


i  +  2  x\  (hfa  hs ). 
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where  wc,wi,,w,,  and  w0  are  the  weight  fractions  of  carbon,  hydrogen,  sulfur,  and  oxygen  in  the  fuel  and  m/^i 
is  the  mass  flow  rate  of  the  fuel.  The  molar  flow  rates  for  die  carbon,  hydrogen,  sulfur,  water,  nitrogen,  and 
oxygen  (including  m0)  for  a  reference  gas  oxidizing  the  fuel  at  stoichiometry  of  one  ae  then  determined  from 

moli=Wi  mjuti  I  niW[ 

where  the  subscript  i  stands  for  one  of  the  above  species  and  the  /mv,-  are  the  molecular  weights  for  these 
species.  By  calling  the  prop  function  with  for  this  reference  combustion  gas  at  a  temperature  of  298.16  K  and  a 
pressure  of  1.0  atm  a  reference  cndialpy  as  well  as  the  equilibrium  composition  can  be  determined.  In  particular 
the  amount  of  water  vapor  in  the  combustion  products  can  be  determined  from  the  mole  fraction  of  water  in  the 
gas  composition.  Knowing  the  higher  heating  value  of  the  fuel  HI IV,  the  heat  of  formation  of  the  fuel  &hform 
can  be  determined  from 


&hfcr„=((.m/ut,  +m0)(h  -kk2o)-i  m/ui,  UHV  lmfuii 

where  h  is  the  reference  enthalpy  calculated  above  and  is  the  saturation  vapor/liquid  water  cndialpy 
difference  times  the  fraction  of  water  within  the  combustion  gasses  given  by 

/iA2o =1050.65*  2344.44*  18.O1534*c0mpA2a/rmi’ 

where  comp  kb,  is  the  mole  fracdon  of  h2o  in  the  reference  gas  and  mw  is  the  molecular  weight  of  the  reference 
gas. 

Once  this  reference  gas  calculation  is  done  the  actual  oxidizing  flow  can  be  used  to  determine  die  actually 
stoichiometry  of  the  combustion  from 


stoich=comp02 


mw. 


31.9988 

m0 


where  comp02  is  the  mole  fraction  of  o2  in  the  oxidizing  flow,  mox  is  the  mas.  t/  the  oxidizing  flow,  and  mwox 
is  its  molecular  weight  The  molar  flow  rates  of  the  actual  combustion  gass  species  consisting  of  the  original 
fuel  species  and  the  actual  oxidizing  flow  species  can  be  determined  from  a  simple  addition 


moli={compi)OI 


Max 

mwox 


+(moli)/lut. 


Here  the  ( moli)[Mi  here  docs  not  include  the  ma  as  used  in  calculation  of  the  reference  gas.  These  molar  rales 
can  be  normalized  to  yield  the  combustion  gas  species  mole  fractions  which  can  then  be  used  through  a  call  to 
the  atom  funedon  to  determine  the  atom  fracdons  for  the  combustion  gas.  The  enthalpy  and  mass  flow  rate  of 
this  gas  is  then  determined  from 

mox  hox  +mfuxi  Ahform 
m-m0I  +  nifmi . 

A  call  to  die  prop  funedon  with  this  enthalpy  as  the  input  (and  at  the  pressure  of  the  oxidizing  flow)  will  then 
give  the  flame  temperature  of  the  combustion  products  as  well  as  their  equilibrium  composidon  and  other  state 
variables. 

For  use  in  power  summaries,  the  input  power  to  the  combustor  is  stored  as 
Pow=mfmillIlV 


The  input  parameters  to  the  model  are 
mass  -  the  mass  flow  rate  (1.0  kg/s)  cf  the  fuel, 

carb  -  the  carbon  weight  fracdon  within  the  fuel  (0.25). 

h  -  the  hydrogen  weight  fraction  within  the  fuel  (0.75). 

o  -  the  oxygen  weight  fracdon  within  die  fuel  (0.0). 

s  -  the  sulfur  weight  fraction  within  the  fuel  (0.0). 
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n  -  the  nitrogen  weight  fraction  within  the  fuel  (0.0). 

h2o  -  the  water  weight  fraction  within  the  fuel  (0.0). 

hhv  *  the  higher  heating  value  (J/kg)  of  the  fuel  (lc7). 

The  model  will  generate  three  additional  output  parameters: 

stoich  -  ratio  of  oxygen  within  the  oxidizer  to  the  amount  of  oxygen  just  necessary  for  100%  fuel  oxi¬ 

dation. 

powcr.hcat  -  total  thermal  power  input  equal  to  hhv  time  the  fuel  mass, 
fl  -  combustion  gas  flow  from  the  model. 

The  combustor  model  should  only  be  used  with  oxidizing  flows  having  the  "GAS"  id.  In  addition  flic  gas  pro¬ 
perties  codes  should  be  compiled  with,  at  least,  the  following  species  -  C,  CO,  C02,  H2, 1120,  S,  S02,  and  N2. 

3.3.12.  Power  (power)  model 

The  power  model  is  somewhat  different  than  the  other  models  in  that  it  docs  not  process  a  particular  flow,  but 
instead,  makes  use  of  a  power  class  used  by  the  other  models.  Each  model  that  produces  work,  such  as  the  gas 
turbine,  or  consumes  work,  such  as  the  pump,  will  record  this  information  in  the  work  parameter  of  a  power 
class.  Similarly,  models  that  input  heat,  such  as  the  combustor,  or  lose  heat  from  the  system,  such  as  a  ht 
model  with  a  negative  heat  load,  will  record  this  information  in  the  heat  parameter  of  this  power  class.  Each  of 
the  model’s  power  class  is  then  put  onto  a  stack,  denoted  as  pows,  by  calling  flic  put  member  function  of  this 
stack  with  flic  model’s  power  class  as  an  argument.  The  power  model  then  makes  use  of  this  pows  stack  to  cal¬ 
culate  flic  net  work  and  heat  associated  with  flic  entire  system.  This  is  done  by  calling  the  c  member  function. 

The  model  has  no  input  parameters,  but  docs  calculate  the  following  output  parameters, 
prod  -  sum  of  all  the  positive  power. work  variables  of  all  models, 

cons  -  sum  of  the  absolute  values  of  all  negative  power. work  variables  of  all  models, 

input  -  sum  of  all  positive  powcr.hcat  variables  of  all  models, 

lose  -  sum  of  the  absolute  values  of  all  negative  powcr.Ioss  variables  of  all  models. 

Note  even  if  the  power  model  is  not  called  the  pows  stack  is  available  for  printing  out  tables  of  the  models’ 
power  classes  via  pows.print.  This  power  class  gives  an  example  of  how  one  can  utilize  information  from  all 
of  the  other  models  and  process  it  in  a  global  way.  Thus,  one  could  add  cost,  reliability,  or  some  other  subclass 
to  each  of  the  model  classes  and  then  add  a  system  cost,  reliability,  or  some  other  model  to  produce  global  sys¬ 
tem  parameters  just  like  this  power  model. 

3.4.  Steady-State  Example  One 

Consider  a  system  consisting  of  a  hydrogen  tank,  a  compressor,  a  heater,  and  a  gas  turbine  connected  together  in 
that  order.  Such  a  system  could  be  analyzed  using  the  following  input  to  GPS. 

cinit 

[/gas  /gasl  /id  "THR-H2"  /t  300  /p  1.0  /m  1.0]  cnew 
[/cp  /cpl  /pres  6.0  /eff  0.88]  cnew 
[/hl/htl  /temp  1000.]  cnew 
[/gt  /gtl  /pres  1.0  /eff  0.84]  cnew 

gasl.c  cpl.c  htl.c  gtl.c 

gass.print  mods.print 
/ail  edei 

Here  we  use  class  gas  (gas  flow  initiator)  to  represent  the  hydrogen  tank  and  define  a  specific  instance  of  that 
class  as  gasl.  Parameter  values  are  then  assigned  to  initialize  the  flow.  These  include  defining  the  flow  as  a 
hydrogen  gas  using  "THR  H2",  and  then  defining  the  values  of  temperature,  pressure,  and  mass  flow  rate  using  t, 
p,  and  m.  Instances  of  flic  compressor,  heater,  and  gas  turbine  classes  arc  then  defined  with  their  associated 
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parameter  values.  Note  that  all  input  parameters  have  default  values  and  thus,  could  be  left  out  if  the  defaults 
are  appropriate  for  the  problem.  Finally,  the  calculational  functions  for  each  class  instance  arc  called  in  the 
order  necessary  for  die  problem  and  the  gas  stack  and  model  stack  print  functions  are  called  to  obtain  the 
results.  As  can  be  seen  the  largest  part  of  the  coding  is  supplying  the  model  parameter  values,  which  is  usually 
the  ease. 

Before  defining  more  complicated  system  configurations,  the  mechanism  for  handling  the  fluid  flow  (or  for 
that  matter  any  type  of  flow)  between  the  models  needs  to  be  considered.  In  the  original  SALT  code,  these 
flows  were  defined  as  structures  that  were  simply  passed  to  the  models  as  arguments.  The  user  of  the  code  basi¬ 
cally  indicated  the  flows  as  either  pass-through,  inputs,  or  outputs.  This  limited  the  models  to  a  fixed  number  of 
flows  and  also  required  that  the  flows  be  declared  and  known  by  the  driver  coding.  In  this  implementation  a 
new  way  of  handling  the  flows  was  developed  that  docs  not  require  them  to  be  known  within  the  driver. 

Basically,  each  model  will  take  off  of  a  flow  stack,  gass,  the  number  of  input  flows  that  it  requires  and  put 
onto  die  stack  die  output  flows  that  it  generates.  Actually,  only  the  address  of  the  flows  are  saved  on  this  stack, 
but  the  concept  is  the  same.  Thus,  in  the  previous  example,  the  gasl.c  model,  being  an  initiator  of  a  flow,  sim¬ 
ply  put  one  output  flow  onto  the  stack,  cpl.c  then  took  this  flow  off  the  stack  and  on  completion  of  its  calcula¬ 
tions,  put  its  output  flow  back  onto  the  stack.  Models  htl.c  and  gtl.c  then  did  exactly  as  the  cpl.c  model  taking 
their  single  input  flow  off  the  stack  and  putdng  their  single  output  flow  back  onto  the  stack. 

In  order  to  handle  arbitrary  system  configurations,  where  some  flows  may  not  be  used  by  the  next  model 
in  the  flew  path,  it  is  only  necessary  to  be  able  to  remove  a  flow  from  the  stack  and,  at  a  later  point,  place  that 
flow  back  on  the  stack  for  further  processing.  For  the  gastype  flows,  this  is  done  by  two  additional  member 
functions  in  the  gas  model  class.  These  two  funedons  are  sav  for  saving  the  flow  (i.e.  remove  from  the  stack) 
and  rec  for  recovering  the  flow  (i.e.  put  back  on  the  stack). 

As  an  example,  suppose  we  have  a  system  consisting  of  a  flow  initiator,  gasl.c,  a  flow  divider1,  dvl.c,  and 
two  heaters,  htl.c  and  ht2.c,  one  for  each  flow  out  of  the  divider.  The  system  configuration  could  be 
represented  by 

gasl.c  dvl.c  gas2.sav  htl.c  gas2.rec  ht2.c 

Here  we  have  used  the  sav  member  function  of  a  second  gas  model,  gas2.sav,  to  save  the  second  flow  from  the 
divider  (i.e.  last  flow  out  of  the  divider  is  on  the  top  of  the  stack).  The  htl  will  then  pick  up  the  first  flow  from 
the  dvl  and  process  iL  The  recover  entry  of  gas2  will  place  the  saved  flow  back  on  the  stack  to  be  processed 
by  die  second  heater,  ht2. 

In  reality,  this  example  only  shows  the  pattern  of  using  the  save  and  recover  functions,  since  in  this  ease, 
we  have  lost  the  flow  from  the  htl  model  for  further  processing  unless  a  third  gas  model  is  used  to  save  it 
before  restoring  the  flow  from  gas2.rec.  Flows  that  arc  generated  by  a  model  and  not  used  immediately  by  a 
subsequent  model  before  other  flows  are  generated  are  lost.  At  any  point  where  a  model  is  called,  one  only 
needs  to  look  at  the  previous  models  to  determine  what  the  input  flows  may  be.  If  a  model  requires  two  input 
flows  and  the  previous  model  only  generates  one  output,  then,  the  model  before  the  previous  will  also  be  used  to 
obtain  an  input  flow.  In  this  ease  the  model  providing  the  first  input  flow  should  probably  be  one  not  requiring 
an  input  flow  itself,  like  the  gas.rec  function.  It  is  the  responsibility  of  the  user  to  correctly  sequence  the  models 
to  represent  the  system  configuration. 

Since  models  that  have  multiple  input  or  output  flows  would  place  these  flows  on  the  flow  slacks  in  a  par¬ 
ticular  order,  it  becomes  necessary  to  remember  this  order  to  properly  save  the  flows  for  later  processing.  Thus, 
most  of  the  models  that  have  such  multiple  inputs  or  outputs  have  secondary  functions  that  do  the  saving  and 
recovering  within  the  model  class  itself.  For  example,  if  the  flow  splitter  is  used  rather  than  the  fictitious  flow 
divider  model  in  the  above  example,  then  the  inputs  would  look  like  the  following. 

gasl.c  spl.c  htl.c  spl.s  ht2.c 

Here,  the  spl  function  only  places  one  now  back  onto  die  gass  stack  for  processing  by  the  htl  model.  The  s 
function  of  the  splitter  model  will  then  place  the  second  or  split-off  flow  onto  the  flow  stack  for  processing  by 
ht2.  Use  of  these  secondary  model  functions  often  eliminate  the  use  of  the  gas  model’s  save  and  recover  func¬ 
tions  and  also  provide  a  clearer  representation  of  the  system  configuration.  They  do  not,  however,  completely 


'This  (low  divider  is  not  actually  in  the  cuncnl  model  libraty,  but  is  only  for  illustration. 
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eliminate  the  use  of  the  gas  save  and  restore  functions.  For  example,  a  gas.sav  would  still  technically  be 
needed  after  htl  if  the  output  of  this  model  were  to  be  further  processed.  These  secondary  functions  generally 
perform  no  modeling,  thus,  for  generating  output  flows,  they  should  be  called  only  after  the  primary  model  func¬ 
tion  is  called  and,  for  obtaining  input  flows,  they  should  be  called  before  the  primary  model  function  is  called. 
An  example  of  the  latter  is  the  use  of  the  mixer  model’s  mxs  function  which  saves  the  input  flow  for  later  use 
when  the  primary  mx.c  function  is  called. 

In  addition  to  the  gastype  flow  class,  other  types  of  flows  may  exist  For  example,  the  dynamic  models  to 
be  discussed  in  the  next  chapter  make  use  of  a  shfttype  flow  class,  representing  the  power  extracted  or  delivered 
to  a  model  by  a  shaft.  These  other  flows  arc  passed  between  the  models  on  a  stack  (a  different  stack  for  each 
flow  type)  exactly  like  the  gas  flows.  Thus,  a  model  may  pick  up  a  gas  flow  from  the  gas  flow  stack  gass  and  a 
shaft  flow  from  the  shaft  flow  stack,  which  is  denoted  as  shfts.  The  different  flow  stacks  arc  entirely  indepen¬ 
dent  of  each  other.  Thus,  in  determining  the  flow  inputs  to  a  model  by  considering  the  previous  model  what  is 
really  meant  is  the  previous  model  generating  an  output  flow  of  the  correct  flow  type.  For  example,  a  shaft  flow 
might  be  generated  and  then  many  models  might  be  called  requiring  only  gastype  flows  before  the  model  that 
requires  the  shfttype  flow  is  called. 

3.5.  Steady-State  Example  Two 

The  last  example  shows  how  to  set  up  a  very  simple  gas  turbine  system,  however,  that  system  is  not  too  realis¬ 
tic.  A  better  example  might  include  some  constraint  on  the  power  generated  by  die  system  to  be  fixed  as  some 
value,  say  40  MW.  This  constraint  which  is  dependent  on  more  dian  one  component  of  the  system  must  be 
specified  by  the  user.  Constraints  like  this  arc  system  related  as  opposed  to  being  component  model  specific, 
and,  depending  upon  the  system  analysis  being  done,  such  constraints  may  not  always  be  required.  Thus,  for 
generality,  these  system  constraints  are  not  automatically  established  by  some  builtin  procedure.  Additionally, 
these  constraints  may  often  be  established  in  more  than  one  way.  For  example,  in  this  ease,  one  might  be  able 
to  establish  this  constraint  by  varying  the  pressure  levels  or  by  varying  the  mass  flow  rale.  In  any  ease  the 
imposing  of  the  constraint  is  not  difficult  and  is  nodiing  more  than  performing  an  equation  solving  task,  where 
the  constraint  equation  is  the  system  power  equal  to  40e6  and  die  parameter  to  be  varied  is,  say,  the  mass  flow 
rate  -  gassl.m.  Adding  this  task  to  the  input  of  example  one,  the  input  becomes  as  follows. 

cinit 

[/gas  /gasl  A  300  /p  1.0  /m  1.0  /id  "THR-tH2"]  cncw 

[/cp  /cpl  /eff  0.88  /pres  6.0]  cnew 

f/ht  /htl  /temp  1000]  cncw 

[/gt  /gtl  /eff  0.85  /pres  1.0]  cnew 

[/task  /a]  cncw 

{a.c} 

{/gasl.m  1.  0.1  50.0  vary 
gasl.c  cpl.c  htl.c  gtl.c 

/gasl.m  (cpl. power,  work+gtl. power.  work-40e6)  cons 

) 

while 

gass  print  mods.print 
/all  cdcl 

Here,  the  task  added  was  denoted  as  a,  and  the  gasl.m  (mass  flow  rate)  variable  was  varied  between  0.1  and 
50.0  starling  at  i  After  the  model  calculationa!  entries  were  called,  the  value  of  die  power  consumed  by  the 
compressor,  which  is  denoted  as  cpl.po.vcr. work,  and  the  value  of  the  power  generated  by  the  gas  turbine, 
gtl. power. work,  will  be  known  and  the  constraint  can  then  be  specified.  When  the  while  loop  for  this  task  a  has 
converged,  the  constraint  will  be  equal  to  zero  (to  the  default  error  tolerance,  since  none  was  specified). 

3.6.  Steady-State  Example  Three 

Condnuing  with  die  preceding  example,  one  might  desire  a  particular  exit  turbine  temperature  or  some  other 
constraint  These  problems  are  solved  by  simply  using  additional  vary  and  cons  operators.  Or  one  might  want 
to  optimize  the  efficiency  subject  to  various  constraints,  both  equality  and  inequality.  These  problems  also  are 
solved  by  simply  using  additional  vary,  cons,  icons,  and  mini  operators.  Here  we  add  a  parameter  sweep  to  die 
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previous  problem.  Suppose  it  is  desired  to  look  at  the  previous  system  for  different  heater  exit  temperatures  of 
say,  800,  1000,  1200,  and  1400.  This  is  accomplished  by  simple  putting  a  for  loop  around  the  task  loop  and  the 
gass  and  mods  print  functions.  The  input  in  these  ease  would  be  as  follows. 

cinil 

[/gas  /gasl  /t  300  /p  1.0  /m  1.0  /id  "THR-tH2"]  cnew 
[/cp  /cpl  /off  0.88  /pres  6.0]  cnew 
[/ht  /htl  /temp  1000]  cnew 
[/gt  /gtl  /eff  0.85  /pres  1.0]  cnew 
[/task  /a]  cnew 
800  200  1400 
(/htl.tcmp  exch  def 
(a.c) 

{/gasl.m  1.  0.1  50.0  vary 
gasl.c  cpl.c  htl.c  gtl.c 

/gasl.m  (cpl.power.work+gtl.powcr.work-40e6)  cons 

} 

while 

gass.print  mods.print 
}  for 
/all  cdcl 

Here  the  starting  value  of  800,  and  increment  of  200,  and  upper  bound  of  1400  are  pushed  onto  the  stack  then 
the  task  loop  and  the  output  functions  are  inserted  into  a  new  procedure  followed  by  the  for  operator.  Since  the 
for  operator  pushes  onto  the  stack  the  value  being  iterated  over,  the  first  line  of  the  new  procedure  takes  this 
value  and  assigns  it  to  the  htl.tcmp.  Note  that  the  print  functions  must  be  within  the  for  loop  otherwise  only 
the  results  for  the  last  value  of  the  heater  temperature  would  be  printed.  In  this  case  the  temperature  values  are 
equally  spaced  and  a  for  loop  could  be  used.  Alternatively  a  forall  loop  could  be  used  with  the  previous  start¬ 
ing,  increment,  and  upper  bound  values  simple  replaced  by  an  arbitrary  array  of  values,  for  example,  [800  925 
1130  1385].  Additional  sweeps  can  be  done  simply  by  nesting  other  iterative  loops  around  that  for  the  heater 
temperature  loop. 

3.7.  Steady-State  Example  Four 

For  the  next  example  we  consider  a  somewhat  more  realistic  example,  a  diagram  of  which  is  shown  in  Figure 
l2.  This  system  is  of  a  simple  space  propulsive  system.  First,  we  consider  the  system  formulated  without  any 
constraints. 

In  Figure  1  a  gastype  flow  is  initialized  using  an  instance  of  the  gas  model,  which  has  been  named 
gas_h2.  As  a  convention  in  naming  the  models  we  will  use  the  model  class  type,  an  underscore,  and  a  label. 
Although,  the  flow  being  initialized  is  a  gastype,  as  explained  previously,  this  really  refers  to  the  flow  class  type 
structure,  and  not  that  the  flow  needs  to  be  a  gas.  In  this  case  the  gas_h2  model  parameters  will  be  defined  to 
initialize  a  hydrogen  flow  within  the  liquid  region.  This  hydrogen  flow  is  then  passed  through  low  pressure  and 
high  pressure  pumps,  denoted  pumpjp  and  pump_hp.  The  flow  then  passes  through  a  heat  exchanger  hx_nz, 
representing  the  nozzle  cooling.  Note,  the  current  nozzle  model  docs  not  include  the  provisions  for  a  coolant 
flow,  thus,  this  heat  exchanger  is  used  to  simulate  these  effects.  The  flow  is  then  split  using  a  splitter,  sp_2,  into 
a  main  flow  and  a  second  flow  which  is  further  split  using  sp_l.  These  last  two  flows  are  then  passed  through 
two  gas  turbines,  gt_hp  and  gtjp  which  are  used  to  drive  the  low  and  high  pressure  pumps.  These  gas  turbine 
flows  arc  then  mixed  together  in  mx_l  and  then  mixed  back  into  the  main  flow  in  mx_2.  The  resulting  flow  is 
then  passed  through  a  heater  model  used  to  simulate  a  reactor,  denoted  as  ht_reac  and  then  through  the  hot  side 
of  the  hx_nz  model  and  out  the  main  thruster  nozzle,  nz_l. 

In  formulating  the  inputs  we  will  start  with  the  model  calls  necessary  to  describe  the  system  configuration. 
This  will  be  done  exactly  like  the  simpler  examples  described  above  by  simply  listing  the  models  in  the  order 
that  they  process  the  gastype  flows  and  using  the  secondary  splitter  and  mixer  functions  where  necessary.  Note, 


1  Note  that  system  diagrams  such  as  shown  in  Figure  1  can  be  scmi-automatically  generated  through  the  GPS  input  itself  as  will  be  dis¬ 
cussed  in  a  later  chapter. 
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Figure  1. 

depending  on  which  flow  from  the  splitters  arc  treated  as  the  primary  flow  and  which  are  treated  as  the  split-off 
or  secondary  flow,  different  system  representations  can  be  defined.  Here  we  will  assume  that  the  primary  flow 
from  sp_2  passes  through  sp_l  and  that  the  primary  flow  from  sp_l  passes  through  the  gtjp  model.  Thus,  the 
system  is  described  up  to  the  secondary  function  of  the  mx_l  model  by 

gas_h2.c  pumpjp.c  pump Jip.c  hx_nz.c  sp_2.c  sp_l.c  gtjp.c  mx_l.s 

At  this  point,  the  secondary  function  of  flic  sp_2  model  can  be  called  to  retrieve  its  split-off  flow  which  is  then 
processed  into  the  secondary  function  of  the  mx_2  model  using 

sp_2.s  mx_2.s 

Then  the  secondary  function  of  the  sp_l  model  can  be  called  to  retrieve  its  split-off  flow.  The  rest  of  the 
models  can  then  be  called  in  the  order  that  they  process  the  flows  as  follows. 

sp_l.s  gt_hp.c  mx_l.c  mx_2.c  ht_rcac.c  hx_nz.h  nz_l.c 

Note,  that  here  the  mixer  models  will  use  the  flows  previously  saved  by  their  secondary  functions.  Also,  note 
that  the  hot  side  function  is  being  called  for  the  hx_nz  model.  The  entire  system  configuration  is  thus 
represented  by 

gas_h2.c  pumpjp.c  pumpjip.c  hx_nz.c  sp_2.c  sp_l.c  gtjp.c  mx_l.s 
sp_2.s  mx_2.s  sp_l.s  gtjip.c  mxj.c  mx_2.c  ht_rcac.c  hx_nz.h  nzj.c 

For  each  of  the  models  used  within  the  system  one  will  need  to  allocate  an  instance  of  the  model  and  to 
define  the  appropriate  model  parameter  values.  These  arc,  of  course,  completely  dependent  on  the  problem.  For 
example,  the  gasji2  model  instance  and  its  parameter  values  might  be  defined  as  follows. 

f/gas  /gasji2  /id  "THR-tH2"  /t  20  /p  1.29  /m  7.387  /v  200]  cnew 

Here  we  define  the  model  with  the  name  gasji2  and  then  assign  its  flow  id  parameter  flic  value  ”THR-tH2". 
(Note,  the  "THR-IH2"  represents  a  hydrogen  gas  flow,  the  small  Y  before  the  H2  denotes  a  special  version  of 
the  hydrogen  data  valid  for  high  temperatures.)  The  rest  of  the  line  then  represent  flic  chosen  initial  values  for 
the  temperature,  pressure,  mass  flow  rate,  and  velocity.  The  other  models  used  would  need  similar  allocations 
and  are  shown  in  the  final  inputs  to  the  problem. 

The  rest  of  the  inputs  to  this  problem  arc  formed  by  adding  the  cinit  call  and  two  additional  function  calls, 
one  to  print  the  gas  flow  output  and  one  to  print  the  model  parameter  output.  We  also  include  in  this  example  a 
call  to  the  power  stack  print  function  pows.print.  Finally,  we  include  a  call  to  the  cdel  operator  to  delete  flic 
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model  classes  used  by  the  problem.  The  final  complete  input  for  this  problem  is  as  follows, 
cinit 

[/gas  /gas_h2  /id  "THR-tH2"  /t  20  /p  1.29  /m  7.387  /v  200  ]  cnew 

[/pump  /pumpjp  /eff  0.67  /pres  7.96  ]  cnew 

[/pump  /pumpjip  /eff  0.81  /pres  139.22  ]  cnew 

[/hx  /hx_nz  /t_cold  (1043.0/1.8)  ]  cnew 

[/sp  /sp_2  /sr  0.3  ]  cnew 

l/sp  /sp_l  /sr  0.3  ]  cnew 

[/gt  /gtjp  /eff  0.23  /pres  85.91  ]  cnew 

[/gt  /gt_hp  /eff  0.75  /pres  85.74  ]  cnew 

[/mx  /mx_l  ]  cnew 

f/mx  /mx_2  ]  cnew 

[/ht  /ht_reac  /temp  (5274/1.8)  ]  cnew 

f/nz  /nz_l  /eff  0.85  /pres  0.1 )  cnew 

[/task  /a]  cnew 

gas_h2.c  pumpjp.c  pump_hp.c  hx_nz.c 

sp_2.c  sp_l.c  gtjp.c  mx_l.s  sp_2.s  mx_2.s  sp_l.s  gt_hp.c 

mx_l.c  mx_2.c  ht_rcac.c  hx_nz.h  nz_l.c 

gass.print  mods.print  pows.print 
/all  cdcl 


The  outputs  for  this  example,  shown  in  Appendix  B,  arc  the  results  of  the  gass.print,  mods.print  and 
pows.print  calls.  The  gass.print  call  displays  the  table  of  state  points  of  exit  flow  from  each  model.  All  units  in 
this  table  arc  in  SI  with  the  exception  of  pressure  which  is  in  atmospheres.  Following  the  state  point  outputs  arc 
the  individual  model  parameter  outputs,  which  were  generated  by  the  mods.print  call.  Finally,  the  table  of 
model  powers  -  input,  loss,  produced,  and  consumed  arc  generated  by  the  pows.print  function. 

In  looking  at  these  outputs  it  can  be  seen  that  if  the  pair  of  models  gtjp  and  pumpjp  were  "  • 
form  a  turbo-pump  then  the  power  consumed  by  the  pump  should  equal  the  power  produced  by  t 
which  is  not  the  case  here.  The  same  situation  holds  with  the  gtjip  and  pumpjip  model  pairs.  Thus,  .•  ,.u 

be  more  appropriate  to  constrain  the  power  produced  and  power  consumed  in  these  two  model  pairs.  This  is 
nothing  more  than  an  equation  solving  task,  similar  to  example  two.  The  first  step  is  tc  determine  what  parame¬ 
ters  could  be  varied  to  establish  these  constraints.  In  general,  there  are  usually  many  parameters  that  could  be 
varied  within  a  system  in  order  to  establish  constraints.  The  only  criteria  is  that  the  constraints  be  functionally 
dependent  on  the  chosen  parameters.  In  this  problem  the  most  obvious  parameters  would  be  the  pressure  levels 
at  the  exit  of  the  models  concerned.  For  this  problem,  however,  the  pressure  levels  out  of  the  models  represent 
the  pressure  leading  to  the  reactor  and  the  nozzle,  and  thus,  arc  important  parameters  of  the  problem.  It  would 
be  best  to  fix  these  at  the  appropriate  design  level  and  vary  some  other  parameters.  Another  set  of  parameters 
might  be  the  split  ratios  at  the  two  splitters.  By  varying  these  split  ratios  varying  amounts  of  mass  flow  can  be 
directed  to  the  two  turbines  generating  more  or  less  power.  Using  these  split  ratios  the  vary  statements  would 
then  look  like  the  following. 

/sp_2.sr  0.3  0.1  0.9  vary 
/spj.sr  0.3  0.1  0.9  vary 

where  here  the  starting  values,  lower  and  upper  bounds  were  taken  as  0.3,  0.1,  and  0.9,  respectively.  The  con¬ 
straints  can  be  taken  as 

/sp_2.sr  (gtjp.po'.ver.'.vork+pumpjp.powcr.work)  cons 
/spj.sr  (gt_hp.powcr.work+pump_hp.powcr.work)  cons 

Here  the  constraint  delimiters  (the  first  argument)  have  been  taken  as  the  two  split  ratios  and  the  actual  con¬ 
straint  expressions  as  the  sum  of  the  respective  models  power. work  variables.  Note,  this  variable  is  algebraic 
with  negative  values  meaning  work  consumed  and  positive  work  produced.  Thus,  the  sum  is  used  rather  than  a 
difference  to  equate  work  consumed  with  work  produced.  Including  the  declaration  of  the  task  itself  and  adding 
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these  vary  and  cons  statements  to  a  task  loop  around  the  model  calls  is  all  that  needs  to  be  done  to  establish 
these  system  constraints.  The  new  complete  inputs  are  as  follows. 

cinit 

[/gas  /gas_h2  /id  "THR-IH2"  /t  20  /p  1.29  /m  7.387  /v200]cncw 

[/pump  /pumpjp  /eff  0.67  /pres  7.96  ]  cncw 

[/pump  /pumpjip  /eff  0.81  /pres  139.22  ]  cnew 

[/hx  /hx_nz  /t_cold  (1043.0/1.8)  ]  cnew 

[/sp  /sp_2  /sr  0.3  ]  cnew 

[/sp  /sp_l  /sr  0.3  ]  cnew 

[/gl  /gt_lp  /eff  0.23  /pres  85.91  ]  cnew 

[/gt  /gt_hp  /eff  0.75  /pres  85.74  ]  cnew 

f/mx  /mx_l  ]  cnew 

[/mx  /mx_2  ]  cnew 

[/ht  /ht_rcac  /temp  (5274/1,8)  ]  cnew 

[/nz  /nz_l  /eff  0.85  /pres  0.1  ]  cnew 

[/task  /a]  cnew 

(a.c) 

{ 

/sp_2.sr  0.3  0.1  0.9  vary 
/sp_l.sr  0.3  0.1  0.9  vary 
gas_h2.c  pumpjp.c  pump_hp.c  hx_nz.c 
sp_2.c  sp_l.c  gtjp.c  mxj.s  sp_2.s  mx_2.s  sp_l.s  gtjip.c 
/sp_2.sr  (gtjp.powcr.work+pumpjp.power.work)  cons 
/spj.sr  (gt_hp.powcr.work+pump  hp.powcr.work)  cons 
) 

while 

mx_l.c  mx_2.c  ht_rcac.c  hx_nz.h  nz_l.c 

gass.print  mods.print  pows.prinl 
/all  cdcl 


Note  that  within  these  inputs  those  models  that  appeared  after  the  gas  turbines  which  don’t  affect  the  constraints 
were  not  included  within  the  task  loop.  This  is  only  a  computational  performance  issue,  as  all  the  models  could 
be  included  if  desired.  In  fact,  the  gas_h2,  pumpjp,  pumpjip,  and  hx_nz  models  could  be  put  before  die 
loop  as  varying  the  split  ratios  will  not  affect  any  of  their  outputs.  If  that  were  done  then  the  system 
configuration  and  task  loop  would  then  look  like  the  following. 

gas_h2.c  pumpjp.c  pumpjip.c  hx_nz.c 
(a.c) 


/sp_2.sr  0.3  0.1  0.9  vary 
/spj.sr  0.3  0.1  0.9  vary 

sp_2.c  spj.c  gtjp.c  mxj.s  sp_2.s  mx_2.s  spj.s  gtjip.c 
/sp_2.sr  (gtjp.power.work+pumpjp.powcr.work)  cons 
/sp  l.sr  (gtjip.power.work+pump  hp.powcr.work)  cons 
} 


while 

mxj.c  mx_2.c  ht_rcac.c  hx_nz.h  nzj.c 


The  resulting  output  for  this  example  is  shown  in  Appendix  C.  The  only  difference  between  this  output 
and  that  within  Appendix  B  is  the  inclusion  of  the  task  loop  iterations  and  the  resulting  changes  within  the  mass 
flow  rates  through  the  system. 


CHAPTER  4 


Dynamic  Power  System  Model  Classes 


4.1.  Introduction 

This  chapter  discusses  the  components  that  are  used  to  perform  a  dynamic  power  system  analysis.  These  models 
consists  of  the  following. 

gas  -  gas  flow  initiator 

sp  -  gas  flow  splitter 

mx  -  gas  flow  mixer 

ht  -  hgas  flow  hcatcr/cooler 

rcac  -  nuclear  reactor 

gt  -  gas  turbine  (based  on  a  performance  map) 

cp  -  compressor  (based  on  a  performance  map) 

pump  -  pump 

cxnz  -  exhaust  nozzle 

pi  -  pipe 

valv  -  valve 

cntl  -  PID  controller 

shft  -  shaft  flow  initiator 

mot  -  motor 

gen  -  generator. 

Note  that  the  names  of  some  of  these  models  are  '  -.actly  the  same  as  those  in  the  steady-state  collection. 
Actually  the  steady-state  collection  could  be  combined  v  eh  these  dynamic  ones,  however,  they  have  been  kept 
separate  for  two  reasons.  The  first  is  that  the  dynamic  models  often  require  much  more  input  information  than 
the  steady-state  models.  Secondly,  many  of  the  dynamic  models  actually  make  use  of  the  diff  function  in  order 
to  define  the  ordinary  differential  equations  of  the  model  and,  in  some  models,  also  use  vary  and  cons  calls  to 
set  up  the  algebraic  equations  representing  the  fluid  mass/momentum  transfers.  This  means  that  the  user  must 
be  more  familiar  with  the  use  of  these  models  and,  in  particular,  will  need  to  define  the  appropriate  task  loops 
within  the  inputs. 


4.2.  Dynamic  Model  Flow  Classes 

The  present  collection  of  dynamic  models  make  use  of  two  flow  classes.  The  first  is  that  of  gastype  and  is 
exactly  the  same  as  that  used  by  the  steady-state  model  collection.  The  other  flow  type  used,  at  present,  is  that 
of  shfttype.  This  flow  type  is  used  to  represent  the  information  present  in  a  shaft  and  consists  of  the  following 
variables. 


rpm  -  shaft’s  rpm 

inertia  -  cumulative  polar  inertia  of  all  components  on  the  shaft 

power  -  cumulative  net  power  delivered  to  the  shaft 

The  shfttype  flows  arc  all  placed  onto  a  stack,  denoted  as  shfts.  The  shfttype  class  has  several  member  func¬ 
tions  one  denoted  as  shftget  is  used  to  retrieves  a  flow  from  this  stack  and  like  the  gasget  is  only  used  internally 
by  the  models.  The  shfts  stack  also  has  a  member  function. print  which  like  the  gass.print  function  can  be  used 
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to  print  out  tables  of  the  exit  shaft  flow  from  the  component  models. 

Like  the  gas  model,  the  shfttype  class  has  a  shft  model  that  is  used  to  initiate  the  shfttype  flow  and,  to 
save  and  recover  the  flow  from  the  shfts  stack. 

4.3.  Dynamic  Models 

At  present,  the  dynamic  models  require  two  different  task  loops.  The  first  is  the  task  dyn  and  represents  the 
dynamic  integrations  over  time  and  the  second,  is  the  task  sta  and  represents  the  calculations  of  die  mass  / 
momentum  transfers  within  the  system.  This  second  task  loop  should  be  nested  within  the  dynamic  task.  A 
more  detailed  discussion  of  these  matters  will  be  presented  after  the  individual  models  have  been  presented. 
Since  both  of  these  tasks  must  be  defined  for  these  dynamic  models  the  allocations  of  these  two  tasks  is  carried 
out  for  the  user  within  the  cinit  function,  and  thus,  no  cncw  calls  need  to  be  made  for  these  two  tasks. 

Some  of  the  dynamic  models  use  a  modeling  that  is  relative  to  rated  or  design  point  values.  Tims,  to 
properly  use  these  models,  the  system  under  analysis  must  be  set  up  and  run  at  this  design  point  first.  This 
design  point  run  will  then  yield  values  that  arc  put  back  into  the  model  as  inputs  for  doing  an  off-design  run, 
such  as  a  system  startup.  In  doing  the  design  point  run  some  of  the  task  functions  used  by  the  models  may  need 
to  be  turned  off.  This  is  uniformly  done  by  using  die  model’s  stat  variable.  Additionally,  the  dynamic  integra¬ 
tions  performed  by  the  dyn  task  would  not  be  done  for  this  design  point  run  and  thus,  do  not  need  to  be  set  up 
within  the  driver  coding. 

In  addition  to  these  design  point  options,  many  of  the  models  have  options  for  setting  up  the  initial  values 
at  the  off-design  starting  points.  For  example,  one  may  wish  to  set  a  particular  temperature  distribution  within 
some  heat  exchanger  or  start  with  some  particular  fuel  temperature  within  a  reactor.  Since  no  special  model 
functions  are  called  to  perform  these  initializations  outside  of  the  task  loops  that  the  user  has  coded  within  the 
inputs,  the  models  need  some  way  of  determining  that  these  initialization  calculations  arc  necessary.  This  is 
accomplished  by  using  the  state  variable  within  the  dyn  task.  As  previously  mentioned,  state  is  used  to  control 
the  integration  procedure.  In  addition,  it  is  used  by  the  dynamic  models  to  inform  them  when  the  initialization 
calculations  arc  needed.  When  dyn^tate  is  zero  the  integration  over  time  has  not  started.  Thus,  die  dynamic 
models  can  check  this  variable  and  perform  their  needed  initializations  or  oilier  calculations  needing  to  be  done 
before  the  integrations  start.  It  should  be  noted,  however,  that  when  a  sta  task  loop  is  nested  within  die  dyn 
task  loop  the  models  will  be  called  many  dmes  while  dyn^tate  is  zero.  In  the  description  of  the  models  below 
the  calls  where  dyn.state  is  zero  arc  referred  to  as  the  initializing  calls. 

4.3.1.  Gas  (gas)  model 

As  with  the  steady-state  model,  the  gas  model  is  used  to  initialize  a  gaslype  flow.  The  model  has  the  initializing 
member  function  denoted  as  c.  This  function  requires  no  input  flows  but  docs  put  one  output  flow  onto  the  gass 
stack. 

The  modeling  consists  basically  of  assigning  the  specified  inputs  to  the  models  exit  flow  values  of  id,  tem¬ 
perature,  pressure,  mass  flow  rate,  quality,  and  composition. 

id=ido 


i=to 


P=P  o 

m  -niQ 

<?=<7o 


compi=comp  o_i 

where  the  subscript  0  indicates  user  specified  values.  The  model  dicn  calls  the  atom  function  to  determine  die 
atom  fractions  of  die  chemical  species  within  the  flow  (note,  that  diis  is  really  only  needed  for  "GAS"  type 
flows).  A  call  to  the  prop  function  wid)  temperature  as  the  input  then  furnishes  the  exit  flow  values  of  endialpy, 
entropy,  and  density.  The  exit  flow  area,  A ,  is  cither  dirccdy  input  or  calculated  based  on  an  input  diameter,  d. 
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assuming  a  circular  flow  cross  section. 

A=nd2l4 

The  exit  flow  velocity  is  then  calculated  from 
v=tnl(Ap) 

where  p  is  the  fluid  density  at  the  exit. 

The  gas  model’s  c  function  will  also  call  vary  to  vary  the  flow’s  mass  flow  rate,  m,  if  the  input  variable 
stat  is  set  to  zero.  If  stat  is  one  then  the  mass  flow  rate  is  simply  taken  as  m  and  is  not  varied.  The  constraint 
to  go  along  with  this  vary  will  be  defined  within  some  downstream  model. 

The  gas  model  also  has  a  function  to  save  a  flow  from  the  g&ss  stack,  denoted  as  sav,  and  a  function  to 
recover  die  flow,  denoted  as  rec  for  representing  complex  system  configurations. 

The  model’s  parameters  are  as  follows, 
id  -  flow’s  id  pointer  ("THR-tH2").  Input, 

t-  flow’s  temperature  (298.16  K).  Input 

p  -  flow’s  pressure  (1.0  atm).  Input 

m  -  flow’s  mass  flow  rate  (1.0  kg/s).  Input, 

v  -  flow’s  velocity  (m/s).  Output, 

comp  -  flow’s  species  mole  fraction.  Input, 

area  -  flow’s  exit  area  (nT).  Input  or  output, 

diam  -  flow’s  exit  diameter  (0.1  m).  Input  or  output. 

stat  -  specifics  whether  or  not  die  steady-state  option  is  in  effect  (0).  Input.  Stat  equal  to  one  turns 

the  option  on,  zero  turns  it  off. 

fl  -  exit  flow  from  the  model.  Note  that  fl  will  need  to  be  further  qualified  with  the  name  of  a  par¬ 

ticular  gastype  parameter,  such  as  "il.t". 

The  id  pointer  should  be  assigned  a  value  of  either  "GAS"  or  "THR-spccics"  as  described  within  the  discussion 
of  the  gastype  flow  class.  At  present,  there  is  no  options  for  starting  a  flow  out  in  the  two  phase  region  as  with 
the  steady-state  gas  model.  If  diam  is  specified  as  zero  then  the  area  parameter  is  used  to  determine  diam,  oth- 
erwise  diam  is  used  to  determine  area.  Thus,  cither  one  or  the  other  of  these  variables  should  be  input. 

4.3.2.  Shaft  (shft)  mode! 

The  shft  model  is  used  to  initialize  a  shfttype  flow  using  the  c  member  function.  This  function  requires  no  input 
flows  and  puts  one  output  flow  onto  the  slifts  stack. 

The  modeling  within  the  shft  model’s  c  function  consists  of  initializing  the  shfttype  flow. 
rpm=rptno 

inertia  =0 


power  =0 


where  rpm0  is  the  specified  input  value. 

The  shaft  model  also  has  a  function  to  save  a  flow  from  the  shfts  stack,  denoted  as  sav  and  a  function  to 
recover  the  flow,  denoted  as  rec.  These  functions  arc  used  exactly  as  with  the  save  and  recover  functions  within 
the  gas  model  for  representing  complex  system  configurations. 


In  addition,  the  shaft  model  has  an  end  member  function  which  is  used  to  define  the  differential  equation 
for  the  shaft  speed.  This  function  requires  one  input  shfttype  flow  from  the  shfts  stack  and  uses  the  information 
within  this  flow  of  the  cumulative  totals  of  power,  power,  supplied  to  the  shaft  and  the  cumulative  totals  of 
polar  moments  of  inertia,  /,  of  models  on  the  shaft  to  define  the  time  rate  of  change  of  the  rpm  as  follows. 
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,  2k  .1  ,  drpm 

( 60 )  r/,m  -~p=P°wer- 

The  model  then  calls  the  task  related  diff  function  with  rpm  as  the  variable  to  be  integrated.  Thus,  this  end 
function  needs  to  be  called  in  order  to  correctly  model  the  speed-up  or  slow-down  of  a  shaft.  Since  this  function 
will  treat  the  rpm  variable  as  a  state  variable  it  should  not  be  input  as  a  function  of  time  within  the  driver  cod¬ 
ing.  If  it  is  desired  to  change  the  rpm  of  the  shaft  directly  as  a  function  of  time  (to  simulate  some  additional 
power  input  or  output)  then  this  end  function  should  not  be  called. 

The  model’s  parameters  arc  as  follows. 

rpm  -  initial  revolutions  per  minute  of  the  the  shaft  (0.0).  Input  and  output, 

drpm  -  time  rate  of  change  of  rpm.  Output. 

inertia  -  total  moment  of  inertia  of  all  the  components  on  the  shaft  (kg  m2).  Output, 

power  -  net  power  supplied  to  the  shaft  (w).  Output. 

shftf  -  exit  shfttypc  flow  from  the  model’s  c  function.  Output.  Like  the  output  gastype  flows  from 

other  models,  shftf  will  need  to  be  further  qualified  with  one  of  the  shfttypc  parameters,  such 
as  "shftf.rpm". 

4.3.3.  Compressor  (cp)  model 

The  compressor  model  is  used  to  model  a  simple  gastype  flow  compression  process.  The  model  is  based  on  per¬ 
formance  maps  rather  than  physical  modeling  mainly  to  keep  the  model  generic  in  nature.  The  performance 
maps  arc  obtained  by  calling  the  in  member  function  which  will  read  the  maps  from  a  file.  Thus,  this  in  func¬ 
tion  needs  to  be  called  once  before  the  calculational  function  is  called.  The  calculational  function  is  denoted  as 
c.  C  requires  one  gastype  input  flow  from  the  gass  stack  and  puts  one  output  flow  back  onto  the  slack.  It  also 
requires  one  shfttypc  flow  from  the  shfts  stack  and  puts  one  shfttypc  flow  back  onto  this  stack. 

The  modeling  used  in  the  compressor  is  dependent  on  whether  die  model  is  being  called  at  a  design  point 
or  an  off-dcsign  point.  If  at  the  design  point,  the  model  calculates  a  rated  corrected  mass  flow  parameter 
cmasSraud  and  a  rated  corrected  speed  parameter  crpmratti.  to- be -used  in  off-dcsign  runs. 

cmassraud=min'fi~/pin 
crpmra„d=r mpin  /  y[i~ 

where  mtn  is  the  inlet  mass  flow  rate,  />,„  is  the  inlet  pressure,  r,„  the  inlet  flow  temperature,  and  rpmM  in  the 
inlet  shaft  rpm.  The  rest  of  the  modeling  is  the  same  whether  at  the  design  point  or  off-deign.  A  corrected 
mass  flow  parameter  cniass  and  corrected  speed  parameter  crpm  are  calculated  from 

Win  ’'fhntPin 
cmass= - 

CimSSraud 


rpmlJ'U~ 

crpm = - . 

crpmnud 

Note  that,  for  the  design  point  these  values  simply  become  1.  The  performance  maps  arc  then  called  with  these 
two  corrected  parameter  values  to  obtain  a  pressure  ratio  pr ^  and  an  efficiency  In  order  to  make  use  of 
the  same  performance  maps  for  different  sized  compressors,  these  returned  map  values  arc  further  scaled  as  fol¬ 
lows. 


pr^U-fpr^p-l) 


(Pirated  0 
^P^nt!ed,map  * ) 


■n® 


rated 

Crated  /nap 


map 


where  the  subscripts  map  refers  to  the  quantity  obtained  from  the  map,  rated  refers  to  the  input  rated  quantity, 
and  rated  .map  refers  to  the  quantity  from  the  map  at  the  rated  conditions. 
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The  pr  value  is  then  used  to  determine  the  exit  pressure 
P~Pr  Pin 

which  is  followed  by  a  call  to  the  prop  function  with  the  inlet  entropy  as  input  to  determine  die  cndialpy  hs  of 
an  iscntropic  compression  to  the  exit  pressure.  The  actual  exit  flow  cntha'oy  h  is  then  determined  from 

h=h;„+(hs-h!n)lr\ 

and  another  call  to  the  prop  function  with  enthalpy  as  the  input  will  then  determine  the  other  exit  flow  state 
values. 

The  power  required  by  the  compressor  is  then  calculated  as 
Pow=m  (h-m -h) 

which  is  then  added  (note  the  power  is  calculated  as  a  negative  number)  to  the  shaft’s  power,  along  with  the 
compressor’s  moment  of  inertia. 

The  input  parameters  to  the  model  arc  as  follows. 

;at_cmass  -  rated  or  design  point  value  of  the  corrected  mass  flow  parameter.  This  value  is  obtained  by 
running  the  model  at  the  design  point  with  the  stat  parameter  specified  as  one,  in  which  ease, 
this  parameter  becomes  an  output  value. 

rat_cspced  -  rated  value  of  the  corrected  speed  parameter.  This  value  is  obtained  as  with  the  rat_cmass 
parameter. 

rat_pr  -  rated  value  of  the  compressor  pressure  ratio  (outlet  to  inlet)  (5.0). 

rat_cff  -  rated  value  of  the  compressor  efficiency  (0.8). 

inertia  -  polar  moment  of  inertia  (5.0  kg  m2)  for  the  compressor. 

file  -  character  array  holding  the  name  of  the  file  containing  the  performance  maps  ("cp.dat"). 

stat  -  flag  for  turning  on  (stat  equal  one)  or  off  (stat  equal  zero)  the  steady-state  design  point  option 

(0). 

Note,  since  the  performance  maps  provide  the  pressure  ratio  and  efficiency  for  the  compressor  there  really  is  not 
much  run-time  input  to  the  model.  However,  the  model  docs  need  to  be  supplied  the  performance  maps  and 
does  need  to  be  run  at  the  design  point  first  in  order  to  obtain  rat_cmass  and  rat_cspccd.  The  two  performance 
maps,  one  for  the  pressure  ratios  and  one  for  the  efficiency,  are  both  stored  in  the  same  input  file  defined  by  the 
parameter  file.  The  details  of  the  data  layout  within  the  performance  map  file  is  described  in  Appendix  G.  The 
output  parameters  from  the  model  arc  as  follows. 

power  -  power  (watts)  required  by  the  compression  process.  Note,  that  like  the  steady-state  models, 

power  is  treated  algebraically  with  negative  values  representing  power  consumed  by  die  model. 
Thus,  in  a  norma!  compressive  process  this  parameter  will  be  negative. 

eff  -  efficiency, 

cmass  -  the  corrected  mass  parameter, 

espeed  -  the  corrected  speed  parameter, 

fl  -  exit  gas  flow  from  die  model, 

shftf  -  exit  shaft  flow  from  the  model. 

4.3.4.  Exhaust  nozzle  (exnz)  model 

The  exhaust  nozzle  model  is  used  to  model  a  nozzle  where  the  back  pressure  is  effectively  zero.  Thus,  die  flow 
will  be  choked  at  the  smallest  cross  sectional  area.  The  model  has  options  for  handling  both  converging  nozzles 
or  converging/diverging  nozzles.  The  input  flow  should  be  subsonic  for  the  model  to  work  properly.  The  calcu- 
lational  member  function  for  the  class  is  denoted  as  c.  c  requires  one  gastype  input  flow  from  the  gass  stack 
and  puts  one  gastype  output  flow  back  onto  this  stack.  Note  that  although  a  flow  is  put  back  onto  the  slack,  diis 
flow  is  only  for  printout  and  should  not  be  used  as  input  for  any  other  downstream  model. 
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The  model  starts  by  calculating  the  area,  A ,  or  diameter,  d,  of  the  throat  section  given  one  or  the  oilier  of 
these  variables  and  assuming  a  circular  flow  cross  section.  A  check  is  then  made  to  make  sure  that  this  flow 
area  is  less  titan  the  inlet  flow  area.  If  it  is  not  the  model  terminates  the  run  with  a  message.  The  model  then 
determines  the  specific  heat  at  constant  pressure  cp  at  the  inlet  temperature  of  the  fluid  by  calls  to  the  prop  func¬ 
tion  and  using  finite  differencing.  The  gas  constant  R  and  ratio  of  specific  heats  y  for  this  flow  are  then  deter¬ 
mined  assuming  that  the  fluid  is  approximately  an  ideal  gas. 

R=pl(pt) 


y =cpl(cp-R). 

These  arc  then  used  to  determine  the  inlet  Mach  number, 

Af=-r^, 

'lyRt 

The  stagnation  temperature, 


r0=t(l+^Af2) 
stagnation  pressure, 

Po=P 

flow  temperature  at  flic  choke  point  or  throat  section, 

2  to 
yt-l 

pressure  at  the  choke  point, 

,  JL 

/>=Po(f)Y*' 


r=- 


k 

and  finally,  the  velocity  at  the  choke  point, 
v=Vy/?7. 

Note,  that  usually,  the  models  within  GPS  do  not  make  use  of  such  constant  specific  heat  equations,  preferring 
instead,  to  iterate  over  flic  property  procedures.  However,  for  the  exhaust  nozzle  the  above  equations  are  rea¬ 
sonably  accurate  and  eliminate  the  iterations  over  the  prop  function  resulting  in  a  faster  running  and  more  robust 
model. 

Knowing  the  flow  conditions  at  the  dural  and  the  area  of  the  throat,  the  mass  flow  rate  required  at  flic 
throat  is  determined  form 


m, 


'rtq 


This  mass  flow  rate  defines  a  constraint  on  the  inlet  flow  rate  and,  for  the  non-stcady-state  option  is  then  used  in 
a  cons  function  call.  For  the  steady-state  option  the  inlet  mass  flow  rate  is  assumed  to  be  the  correct  value  and 
the  area  at  flic  throat  is  then  calculated  from 

A=mWi!y  Ip 


If  a  value  was  furnished  to  the  variable  Actp,  representing  any  additional  expansion  beyond  the  throat  sec¬ 
tion,  the  flow  is  expanded  by  iterating  over  flic  exit  Mach  number,  and  using  relations  similar  to  above,  calculat¬ 
ing  flic  exit  flow  temperature,  pressure,  and  velocity,  and  hence,  area.  When  flic  calculated  area  is  the  same  as 
dexp  the  iterations  are  terminated,  yielding  the  final  exit  Mach  number  as  well  as  exit  flow  state  variables. 

For  use  in  print  out  the  thrust  and  specific  impulse  arc  calculated  as  follows. 
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thrust=mv+pAcxp 
impulse  =thrust  1(9. 8m ). 

Note,  Unit  when  A„p  is  not  furnished  the  thrust  calculation  uses  the  throat  area  instead. 

The  parameters  to  the  model  arc  as  follows, 
diam  -  throat  (smallest)  section  diameter  of  the  nozzle  (0.05  m).  Input. 

area  -  throat  area  (m2).  If  diam  is  set  to  zero  then  area  determines  diam,  otherwise  diam  is  used  to 

determine  area. 

aexp  -  divergent  section  exit  area  (0.0  m2).  If  aexp  is  less  than  area  no  divergent  section  is  calculated. 

mach  -  initial  estimate  of  the  exit  Mach  number,  only  used  when  aexp  is  non-zero  (1.5). 

stat  -  steady-state  options  flag,  one  for  steady-state  option  on  and  zero  for  off  (0).  Input. 

mrcq  -  mass  required  by  the  throat  section.  Output. 

thrust  -  thrust  generated  by  the  exiting  flow  (nt).  Output. 

impulse  -  specific  impulse  of  the  nozzle  (s).  Output. 

fl  -  exit  flow  from  the  model.  Output. 

4.3.5.  Gas  turbine  (gt)  model 

The  gas  turbine  model  is  used  to  model  a  simple  gastype  flow  expansion  process.  The  model  is  based  on  per¬ 
formance  maps  rather  than  physical  modeling  mainly  to  keep  the  model  generic  in  nature.  The  performance 
maps  arc  obtained  by  calling  the  in  member  function  which  will  read  the  maps  from  a  file.  Thus,  this  in  func¬ 
tion  needs  to  be  called  once  before  the  calculational  function  is  called.  The  calculational  function  is  denoted  as 
c.  C  requires  one  gastype  input  flow  from  the  gass  stack  and  puts  one  output  flow  back  onto  the  stack.  It  also 
requires  one  shfttypc  flow  from  the  shfts  stack  and  puts  one  shfttype  flow  back  onto  this  slack. 

The  gas  turbine  model  is  very  similar  to  the  compressor  model  the  only  difference  being  the  calculation  of 
the  exit  flow  enthalpy,  which  for  the  turbine  is  given  by 

h  ~  *1  (hs  —  ll;„  ) 

and  the  calculation  of  the  exit  pressure 
P=PiJpr 

where  the  notation  is  the  same  as  that  used  in  the  compressor  model. 

The  parameters  to  the  model  arc  as  follows. 

rni_cmass  -  rated  or  design  point  value  of  the  corrected  mass  flow  parameter.  This  value  is  obtained  by 
ii.-ining  model  at  the  design  point  with  the  stat  parameter  specified  as  one,  in  which  ease, 
ti> .  pr  r  becomes  an  output  value. 

rat_cspccd  -  rated  v_  t.  of  the  corrected  speed  parameter.  This  value  is  obtained  as  with  the  rat_cmass 
parameter. 

cmass  -  the  corrected  mass  parameter.  Output, 

espeed  -  the  corrected  speed  parameter.  Output. 

rat_pr  -  rated  value  of  the  expansion  pressure  ratio  (inlet  to  outlet)  (5.0).  Input. 

rat_cff  -  rated  value  of  the  gas  turbine  efficiency  (0.82).  Input, 

inertia  -  polar  moment  of  inertia  (kg  m2)  for  the  device.  Input. 

file  -  character  array  holding  the  name  of  the  file  containing  the  performance  maps.  Input, 

stat  -  steady-state  options  flag,  one  for  steady-slate  option  on  and  zero  for  off  (0).  Input, 

eff  -  efficiency.  Output. 
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power  -  power  (watts)  generated  by  the  expansion  process.  Output 

II  -  the  exit  gas  flow  from  the  model.  Output, 

shftf  -  the  exit  shaft  flow  from  the  model.  Output. 

As  with  the  compressor  model,  there  arc  two  performance  maps  for  the  turbine  both  stored  in  the  same  input 
file.  The  first  supplies  a  pressure  ratio  as  a  function  of  the  corrected  mass  and  corrected  speed  and  the  second 
gives  the  efficiency  as  a  function  of  the  corrected  mass  and  corrected  speed.  The  details  of  die  data  layout 
widiin  the  performance  map  file  is  described  in  Appendix  G. 


4.3,6.  Heater  (ht)  model 

The  heater  model  represents  the  transfer  of  heat  into  or  out  of  a  gaslype  flow.  The  moo.i  has  one  calculalional 
member  function  denoted  c.  This  function  requires  one  input  gastype  flow  from  the  gass  stack  and  outputs  one 
gastype  flow  back  to  the  stack. 

There  arc  several  options  to  this  model.  The  first  is  a  steady-state  mode  in  which  the  heal  input  Q  is  sim¬ 
ply  added  to  the  inlet  flow  cndialpy  h;„  to  generate  the  exit  enthalpy. 


h=h!n  +  Q/m 

where  m  is  the  mass  flow  rate  of  the  fluid.  The  pressure  drop  Ap  dirough  the  heater  is  given  as 

12 


Ap  — /  rated  Pin 


m 


Mroled 


where  die  subscript  rated  refers  to  some  input  rated  value  and  /  is  die  fracdon  of  the  inlet  flow  representing  die 
pressure  drop.  The  exit  flow  pressure  is  then  given  by 


P=Pin-Ap 

and  the  other  exit  flow  parameters  are  then  obtained  from  a  call  to  the  prop  funcuon. 

The  second  option  is  a  simple  thermal  delay  mode.  This  option  permits  a  number  of  nodes  along  the  dev¬ 
ice,  with  the  exit  enthalpies  for  each  node  given  by 

3/i/  m  (/»,_]  -/»,)+ Qi  . 
di~  K  *  '  ~  ’-,n 

where  K  is  some  input  constant,  n  is  the  number  of  nodes,  and  Q,  is  die  amount  of  heat  transferred  at  each 
node.  Presendy  Q ,  is  taken  as  Q In.  In  this  mode  the  pressure  at  the  exit  of  each  node  is  defined  as 


Pi-Pi-\-Ap  In 

where  Ap  is  calculated  as  above.  Note  that  diis  option  is  provided  for  diosc  eases  when  one  simply  does  not 
have  enough  informadon  concerning  the  heater  to  make  use  of  the  full  calculadonal  mode  but  still  desires  some 
thermal  delay  to  be  included. 

The  final  or  full  calculalional  mode  again  makes  use  of  multiple  nodes,  widi  both  a  wall  temperature  and 
fluid  enthalpies  at  each  node  calculated  from  die  following. 

37', 

cpM,-z~=Q,-uaAit 


=m  -  hi )  +  na  At, 


where 


Ati=Ti  —  (r,  +t,.\)l2. 

Here  T,  is  the  wall  temperature  at  die  i-th  node,  u  is  the  ovci  all  heat  transfer  coefficient,  a  is  the  heat  transfer 
surface  area,  cp  is  the  wall  specific  heat,  and  M ,  is  die  wall  mass  at  the  i-di  node.  The  exit  pressure  at  each 
node  is  determined  as  with  the  previous  mode  and  the  other  flow  state  variables  are  dicn  determined  with  a  call 
to  the  prop  function  with  enthalpy  as  the  input.  Hie  u  that  is  used  in  the  above  equation  is  adjusted  for  changes 
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in  mass  flow  rate  from  flic  rated  flow  using 


li  —Urattd 


m 

Wrattd 


where  urauj  is  the  heat  transfer  coefficient  at  mraU<t.  The  flow  propen,  ^  at  the  exit  of  the  heater  arc  taken  as 
those  at  the  last  node.  Finally,  for  all  modes,  the  exit  velocity  is  calculated  as 

v=m/(p,A) 

where  A  is  the  exit  flow  area. 

The  input  parameters  to  the  model  arc  as  follows. 

num  -  number  of  internal  nodes  along  the  flow  path  within  the  model  (0).  If  greater  than  zero,  the 

total  heat  transferred  is  equally  divided  into  this  many  parts  with  each  part  transferred  per 
node.  If  equal  to  zero,  the  model  works  like  a  steady-state  model  with  the  resulting  flow 
enthalpy  changing  instantaneously  with  the  heat  transfer. 

t#i  -  the  flow  temperature  of  the  i-th  node.  This  array,  which  should  be  defined  for  i  from  to  one  to 

num,  represents  the  initial  gas  temperature  distribution.  Thereafter  t#i  will  be  an  output.  If 
num  is  zero,  this  array  is  not  used. 

heat  -  the  total  heat  load  on  the  exchanger  (le5  w).  Generally,  heat  is  used  as  an  input  only  after  the 

initial  call  to  the  model,  however,  heat  can  be  used  on  the  initializing  call  to  generate  the 
values  of  the  t  array. 

diam  -  diameter  of  the  total  flow  passage  through  the  device  (0.1). 

area  -  area  of  flic  total  flow  passage  through  the  device.  If  diam  is  zero  then  area  is  used  to  deter¬ 

mine  diam,  otherwise  area  is  determined  by  diam. 

length  -  length  of  the  flow  passage  through  the  device  (1.0  m).  Note  length  and  area  arc  used  to  deter¬ 

mine  the  volume  of  the  device  and  not  the  heat  transfer  surface  area  which  is  supplied  by  ua. 

ua  -  heat  transfer  surface  area  time  the  heat  transfer  coefficient  per  node  at  the  rated  flow(le5  w/K). 

rat_m  -  rated  or  design  point  mass  flow  rate  through  the  device  (5.0  kg/s).  This  is  used  to  adjust  the  ua 

value  and  pressure  drops  for  different  off-design  flow  rates. 

rat_pf  -  rated  or  design  point  pressure  drop  through  the  device  as  a  fraction  of  the  inlet  pressure  (0.05). 

twallffi  -  wall  temperature  array.  This  array  is  used  to  give  initial  values  for  the  gas  passage  wall  tem¬ 

peratures.  After  the  initializing  call  this  array  will  be  an  output  Note  that  this  array  is  used 
only  if  the  wall  is  given  a  mass  using  mwall. 

mwall  -  mass  of  the  walls  containing  the  gas.  If  mwall  is  non-zero  then  the  code  will  make  use  of  the 

full  calculational  mode  and  calculate  the  wall  temperatures.  In  this  ease  the  heat  load  is  distri¬ 
buted  uniformly  along  the  wall, 

cpwall  -  specific  heat  of  the  wall  material  (1000  J/kg  K). 

tconst  -  constant  used  for  heat  transferred  to  the  gas  in  the  simple  thermal  delay  option  (10).  Tconst 

represents  the  K  defined  above. 

As  noted  some  of  these  variables  are  used  as  inputs  only  on  the  initializing  call  to  the  model  and  arc  sub¬ 
sequently  defined  as  outputs.  Thus,  one  needs  to  be  cautious  when  calling  this  model  within  a  loop.  Iterating 
over  different  values  of  heat  as  inputs  to  establish  some  initial  constraint,  for  example,  will  not  work.  This  is 
because  once  the  model  is  called  with  heat  as  an  input,  the  t#i  array  is  then  defined,  and  hence  on  subsequent 
iterations,  this  t#i  array  would  be  used  rather  than  the  heat  parameter.  However,  one  could  iterate  over  the  t#i 
values.  Output  parameters  form  the  model  include 

hcatO  -  initial  heat  load  on  the  device  (w).  This  can  be  used  on  subsequent  calls  to  give  continuity  to 

the  thermal  input  using  the  heat  parameter  when  the  t#i  array  is  used  on  the  initializing  call. 

flow  area  times  the  heater  length  (m3). 
exit  flow  from  the  model. 


vol  - 
fl  - 
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4.3.7.  Mixer  (mx)  model 

The  mixer  model  mixes  together  two  gastype  flows.  The  calculational  member  function  is  c  and  requires  one 
input  flow  from  the  gass  stack  and  puts  one  output  flow  back  onto  the  stack.  The  other  input  flow  is  obtained 
by  calling  the  member  function  s.  This  s  function,  which  must  be  called  before  the  c  function,  requires  one 
input  gastype  flow  but  generates  no  output  flow. 

As  with  the  most  of  the  other  dynamic  models  the  exit  flow  area  is  calculated  using  a  specified  diameter  d 
by 

A=nd2/4 

or  if  the  area  is  input  the  diameter  is  determined  from  the  same  equation.  The  exit  mass  flow  rate  is  ealeu  lt.v. 
from 


m=mi+/n2 

where  the  subscripts  refer  to  the  two  inlet  flows.  The  exit  flow  enthalpy  is  obtained  from 
,  mihi+m2h2 

h= - 

m\+m2 

and  the  exit  flow  velocity  from 
v=ml(pA) 

where  the  exit  flow  density  is  obtained  from  a  call  to  the  prop  function  with  enthalpy  as  the  input. 

In  the  dynamic  mode  the  mixer  model  imposes  a  constraint  on  the  entering  flows  that  their  pressures 
should  be  equal.  This  is  done  by  calling  the  task  class  cons  function.  In  the  steady-state  mode  this  constraint  is 
not  imposed.  In  cither  case,  the  exit  pressure  is  defined  to  be  the  mass  weighted  average  of  the  inlet  pressures 

Ml/?  1+17120  2 

p~ - . 

mi+m2 

In  a  dynamic  problem  the  inlet  flow  rates  entering  a  mixer  should  rapidly  adjust  themselves  such  that  the  inlet 
pressures  become  equal.  For  the  instantaneous  representation  of  the  mass  /  momentum  effects  us^d  by  the 
models  these  pressures  are  thus,  simply  constrained  to  be  equal.  The  actual  parameter  that  is  varied  to  order  to 
establish  this  constraint  will  appear  within  some  other  upstream  model. 

The  parameters  for  the  model  arc: 
diam  -  exit  flow  diameter  (0.01  m).  Input. 

area  -  exit  flow  area.  If  diam  is  zero,  diam  is  determined  by  area,  otherwise  area  is  determined  by 

diam. 

stat  -  flag  used  to  turn  on  (stat=l)  or  turn  off  (stat=0)  the  dynamic  mode  constraint  on  inlet  flow 

pressures  (0). 

dp  -  difference  in  input  flow  pressures  (atm).  Output, 

fl  -  exit  flow  from  the  model.  Output. 


4.3.8.  Pipe  (pi)  model 

The  pipe  model  models  the  pressure  drop  and  optionally  the  enthalpy  delays  that  occur  within  pipes.  The  model 
has  a  calculational  member  function,  c,  requiring  one  input  gastype  flow  from  the  gass  stack  and  puts  one  output 
flow  back  on  the  slack. 


The  pipe  model  is  similar  to  the  heater  model  in  the  way  that  it  calculates  pressure  drops.  11a  model  also 
can  make  use  of  multiple  nodes  in  representing  enthalpy  delays.  Thus,  the  exit  pressure  and  enthalpy  form  each 
node  is  calculated  from 


Pi=Pi.]-Ap  In 
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an; 

PiV;—=m 


where  p,=(Pi+Pi-i)/2,  V,  is  ihc  i-lh  node  volume,  and  n  is  the  total  number  of  nodes.  Finally,  the  exit  flow 
velocity  is  determined  from 


v=ml(rho  A  npar) 

where  A  is  the  pipe,  n ^  is  the  number  of  pipes  passing  the  flow  in  parallel.  If  the  number  of  nodes  is  taken  as 
zero,  the  model  only  calculates  the  pressure  drop  and  no  enthalpy  delays  are  calculated. 

The  parameters  for  the  model  are  as  follows, 
diam  -  exit  flow  diameter  (0.1  m).  Input. 

area  -  exit  flow  area.  As  with  the  other  models,  if  diam  is  non-zero,  diam  determines  area,  otherwise 

area  determines  diam. 


length  - 
rat_pf  - 
ral.u  - 
num  - 


num_par  - 
dp- 
fl  - 


length  of  the  pipe  (1.0  m).  Input. 

rated  or  design  flow  rate  pressure  drop  as  a  fraction  of  the  inlet  pressure  (0.01).  Input 
rated  or  design  flow  rate  (1.0  kg/s).  Input. 

number  of  nodes  along  the  pipe  length  (0).  Input  This  is  used  to  define  the  differential  equa¬ 
tions  to  simulate  thermal  delays.  If  num  is  zero,  no  thermal  delays  are  modeled.  For  gas 
flows  in  short  pipes  num  equal  zero  is  generally  sufficient 

number  of  parallel  flow  segments  or  pipes  in  parallel  that  the  model  represents  (1).  Input, 
total  pressure  drop  along  the  pipe  (atm).  Output 
exit  flow  from  the  pipe.  Output 


4.3.9.  Pump  (pump)  model 

The  pump  model,  like  the  gas  turbine  and  compressor,  is  based  on  performance  maps  rather  than  basic  physical 
modeling.  Again,  this  was  done  in  order  to  have  a  generic  model  rather  than  a  pump  of  a  specific  type.  The 
performance  maps  are  obtained  using  the  member  function  in.  This  function  should  be  called  once  before  the 
calculational  function  is  called.  The  layout  of  the  data  within  the  performance  map  file  is  discussed  in  Appen¬ 
dix  G. 

The  calculational  function  is  denoted  c.  This  function  requires  one  input  gastype  flow  from  the  gass  stack 
and  puts  one  output  gastype  flow  back  onto  this  stack.  The  function  also  requires  one  shfttype  flow  from  the 
shfts  stack  and  puts  one  shfttype  flow  back  onto  the  shfts  stack.  The  pump  model  makes  use  of  homologous 
pump  head  and  torque  curves.  These  take  the  head  as  a  function  of  the  normalized  flow  and  rpm  as  follows. 


rpmn= 


rpm 

rpmruud 


jc=7t+tan-1( - ) 

rpmn 


11 =(m„2 + rpm?)  H(x )  Hrttltd 

where  1!  is  the  pump  head,  H  is  the  pump  head  function,  and  the  subscripts  rated  stands  for  rated  values  and  n 
for  normalized  values.  The  torque  T  is  calculated  given  the  pump  efficiency,  t),  as 

j  60  mil 
2 it  pr ]rpm' 

The  torque  can  optionally  be  obtained  from  the  homologous  pump  curves  as 
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T =(m?+rpm?)  T(x)  Tnud 

anti  then  the  efficiency  is  calculated  from  the  previous  equation.  (Note,  that  due  to  lack  of  good  pump  torque 
curves  the  first  approach  with  the  efficiency  given  is  currently  hardwired  in  the  coding.)  The  exit  flow  state  vari¬ 
ables  are  then  determined  from 

P=Pin+H 

h=hin  +HI(pr\) 
and  a  call  to  the  prop  function. 

The  power  required  by  the  pump  is  calculated  as 
Pow=m  (h;H -h) 

which  is  then  added  to  the  exit  shft  flow.  In  addition,  the  pumps  moment  of  inertia  is  also  added  to  the  exit  slift 
flow. 

The  parameters  for  the  model  are  as  follows. 
rat_m  -  rated  or  design  point  mass  flow  (1.0  kg/s)  for  the  pump.  Input. 

rat_rpm  -  rated  design  point  rpm  (1000).  Input 
rai_dp  -  rated  design  point  pressure  rise  (5.0  atm).  Input 

rat_eff  -  rated  design  point  efficiency  (0.85).  Input, 

eff  -  pump  efficiency  (0.65).  Input 

inertia  -  polar  moment  of  inertia  (0.1  kg  m  2).  Input 

dp  -  pressure  rise  across  the  pump  (atm).  Output. 

power  -  power  required  by  the  pump  (w).  Output.  Like  the  compressor  model,  this  parameter  will 

appear  as  a  negative  number  for  power  consumed. 

fi  -  exit  gas  flow  from  the  pump.  Output. 

shftf  -  exit  shaft  flow  from  the  pump.  Output. 

file  -  file  containing  the  performance  maps  ("pump.dat").  Input 

The  model  makes  use  of  two  performance  maps  both  contained  in  the  file  defined  by  the  parameter  file. 
The  first  gives  a  nondimensional  head  curve  as  a  function  of  the  nondimensional  flow  rate  and  nondimcnsional 
rpm.  The  nondimensionalizing  factor  in  all  cases  is  the  rated  condition  of  the  corresponding  variable.  The 
second  performance  map  is  of  the  nondimensional  torque  as  a  function  of  the  same  two  nondimcnsional  parame¬ 
ters.  Note  that  unlike  the  gas  turbine  and  compressor  models,  this  model  does  not  need  to  be  run  at  the  design 
point  first. 


4.3.10.  Reactor  (reac)  model 

The  reactor  model  is  also  very  generic  in  nature  being  predominately  a  heat  exchanger,  although,  point  kinetic 
equations  are  also  provided  as  an  option.  The  model  has  a  main  calculational  member  function  denoted  c.  The 
function  requires  one  input  gastype  flow  and  generates  one  gastype  output  flow. 

If  the  point  kinetics  option  is  specified,  the  following  equations  are  solved  for  the  neutronics. 


dCj  P  jPf 

dt  ~  r 


where  P{  is  the  fission  power,  c,  is  the  precursor  nuclei  concentrations,  X,  is  the  radioactive  decay  constants,  P, 
is  the  i-th  fraction  of  delayed  neutrons,  P  is  £P, ,  p  is  the  reactivity,  and  /*  is  the  prompt  neutron  generation 
time.  The  reactivity  is  presently  taken  as  follows. 
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P— Pc/nl  '^'Pcoo!  U'cool  Tcool  ,o) 

where  pen,i  is  the  control  reactivity,  pcool  is  the  coolant  feedback  reactivity  ,  Tcool  is  the  average  coolant  tem¬ 
perature,  and  Tcoot  ,o  is  the  initial  Tcool.  If  the  point  kinetics  option  is  not  on,  then  the  fission  power  is  assumed 
to  be  an  input. 

The  fission  power  is  assumed  to  be  dissipated  in  the  fuel  mass.  The  resulting  fuel  temperature,  cladding 
temperature,  and  coolant  flow  exit  enthalpy  is  then  obtained  from  the  following  equations. 

dTfuti  P f  -Uclad(Jfuil-Tctod) 

dt  CPfiulMfuil 

^  clad  Uclod(TfMi—l  ciaj)~Uc00i(&Tm) 
dl  CPclad  ^  clad 

dh  _Ucooi(.&rm)+tn(h-M-h) 

dt  p  vol 

where  T  is  the  average  temperature,  A Tm  is  the  log  mean  temperature  difference,  h  is  the  exit  coolant  enthalpy, 
hM  is  the  entrance  coolant  enthalpy,  cp  is  the  specific  heat,  M  is  the  mass,  p  is  the  average  coolant  density,  vol 
is  the  coolant  passage  volume,  u  is  the  heat  transfer  coefficient,  and  the  subscripts  denote  whether  the  quantity 
is  the  fuel,  cladding,  or  coolant  fluid.  The  ucoot  coefficient  is  also  adjusted  based  on  the  fluid  flow  rate  as  fol¬ 
lows. 


ttcool  ~tiC00l  solid  ( 


m 


\0.8 


fflroud 


where  ucool  ja ud  is  the  heat  transfer  coefficient  at  the  rated  mass  flow  rate. 

The  pressure  drop  through  the  reactor  is  given  exactly  like  the  heater  model  based  on  a  pressure  drop  frac¬ 
tion  and  adjusted  as  a  function  of  the  mass  flow  rate.  The  rest  of  the  exit  flow  state  variables  are  then  deter¬ 
mined  from  a  call  to  the  prop  function  with  enthalpy  as  in  input  and  the  exit  flow  velocity  is  determined  from 

v=m  l(pA) 

As  an  option,  the  cladding  mass  may  be  set  to  zero  in  which  case  the  calculation  of  the  cladding  temperature  is 
not  done. 

The  input  parameters  to  the  model  are  as  follows. 

rat_m  -  rated  or  design  point  mass  flow  through  the  reactor  (5.52  kg/s).  This  parameter  is  used  to  scale 

off-design  pressure  drops. 

rat_pf  -  rated  pressure  drop  through  the  reactor  as  a  fraction  of  the  inlet  pressure  (0.2). 

tcool  -  initial  value  of  the  exit  gas  flow  temperature  (K). 

power  -  power  level  generated  by  the  reactor  (lc6  w).  This  is  either  an  input  for  all  time  or,  if  the 

point  kinetic  equations  arc  used,  an  initial  value  parameter. 

ucool  -  heat  transfer  film  coefficient  for  the  gas/cladding  or  gas/fuel  interfaces  at  the  rated  flow  (1.3c6 

w/K). 

uclad  -  heat  transfer  coefficient  between  the  fuel  and  cladding  (1.3e6  w/K).  Uclad  is  only  used  when 

meald  is  non-zero. 

mfucl  -  mass  of  the  fuel  material  (220  kg). 

mclad  -  mass  of  the  cladding  material  (0.0  kg).  If  mclad  is  set  to  zero,  no  cladding  material  is 

assumed. 

cpfuel  -  specific  heat  of  the  fuel  (1000  J/(kg  K)). 

cpclad  -  specific  heat  of  the  cladding  (1000  J/(kg  K)). 

tclad  -  initial  value  of  the  cladding  temperature.  If  tclad  is  set  to  zero,  then  it  is  taken  as  an  equili¬ 
brium  value  (i.c.  its  time  rate  of  change  is  zero)  based  on  the  power  and  heat  transfer 
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coefficients.  Tclad  is  only  used  if  mclad  is  non-zero. 

tfucl  -  initial  value  of  the  fuel  temperature.  If  tfucl  is  set  to  zero,  then  an  equilibrium  fuel  tempera¬ 

ture  based  on  the  power  and  heat  transfer  coefficients  is  used. 

diam  -  diameter  of  the  exit  flow  area  (0.2  m). 

area  -  area  of  the  exit  flow.  Diam  and  area  are  used  to  determine  each  other  as  with  the  other 

models. 

vol  -  volume  of  the  gas  passage  within  the  reactor  (1.0  M3). 

rcactcnd  -  control  reactivity  (0.0). 

rcactcool  -  temperature  coefficient  of  the  reactivity  (0.0).  The  total  reactivity  is  taken  as  reactcntl  plus  this 
coefficient  times  the  difference  of  the  average  coolant  temperature  and  the  initial  average 
coolant  temperature.  The  average  is  taken  as  the  mean  of  the  inlet  and  exit  temperatures. 

option  -  flag  used  to  turn  on  (option  equal  one)  or  off  (option  equal  zero)  the  point  kinetic  calculations 

(0). 

bcta#i  -  fraction  of  neutrons  in  the  i-th  delayed  group,  i  goes  from  0  to  5  (0.00021,  0.00141,  0.00127, 

0.00255,  0.00074,  0.00027). 

bet  -  fraction  of  neutrons  which  are  delayed  (0.00645).  Note,  the  code  internally  normalizes  the  beta 

array  so  that  its  elements  sum  to  bet 

lambffi  -  radioactive  decay  constant  of  the  i-th  group  of  precursors,  i  goes  from  0  to  5  (0.0124,  0.0305, 

0.111,0.301,1.1,3.0). 

The  beta,  bet,  and  lamb  parameters  arc  only  used  if  option  is  set  to  one.  The  outputs  from  the  model  include 
tcoolO  -  initial  average  coolant  temperature  (K). 

powciO  -  initial  power  level  (w). 

11  -  exit  flow  from  the  reactor. 

4.3.11.  Splitter  (sp)  model 

The  splitter  models  the  splitting  of  a  gastype  flow  into  two  flows.  The  model  has  a  calculational  member  func¬ 
tion  c  which  requires  one  input  gastype  flow  and  generates  one  output  gastype  flow.  The  other  output  flow  is 
obtained  by  calling  the  member  function  s,  which  should  be  called  only  after  the  c  function  has  been  called. 

The  dynamic  splitter  model  works  much  like  the  steady-state  splitter  model  but  only  includes  die  full  flow 
splitting  and  not  the  species  splitting.  Thus,  given  a  split  ratio  sr  the  two  exit  flows,  denoted  by  subscripts  1  and 
2,  are  obtained  from  the  following. 

m\-sr  mM 

v1=mi/(p4,) 

V2=m2/(p/42) 

The  temperature,  pressure,  enthalpy,  etc.  for  the  exit  flows  are  the  same  as  the  input  values.  Note  that  the  split 
ratio  is  varied  for  dynamic  runs. 

The  parameters  to  the  model  arc: 

diamffi  -  diameter  (m)  of  the  i-th  exit  flow  with  i  being  either  0  or  1  (0.01  m).  Input. 

area/fi  -  area  of  the  i-th  exit  flow.  If  diam#i  is  zero  the  diamf/i  is  determined  from  area#i,  else  arcaSi  is 

determined  from  diam#i. 

stat  -  flag  used  to  turn  on  (stat  equal  one)  or  off  (stat  equal  zero)  the  steady-state  option  (0).  Input. 

sr  -  split  ratio  of  the  second  output  flow  to  the  inlet  flow  (0.5).  Input.  If  slat  is  zero  then  this 

parameter  only  represents  an  initial  value  and  is  thereafter  determined  by  some  system 
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constraint 

fl#  -  exit  flows  from  the  model.  Output. 

The  splitter  model  generates  a  new  gastype  flow  and  as  such  will  vary  the  mass  flow  rate  for  the  flow  pro¬ 
vided  that  stat  is  zero.  This  is  done  by  varying  the  sr  parameter.  When  stat  is  one,  the  specified  split  ratio  is 
not  changed. 

4.3.12.  Valve  (valv)  model 

The  value  model  has  two  options,  one  using  a  conductance  factor  and  valve  position  along  with  an  empirical 
expression  for  die  flow  rate  that  can  be  passed  as  a  function  of  the  pressure  drop,  and  a  second  option  in  which 
the  pressure  drop  is  directly  input,  the  valve  position  being  determined  after  the  fact.  The  model  has  a  calcula¬ 
tion  member  function  c  requiring  one  input  gastype  flow  and  generating  one  output  gastype  flow. 

In  the  first  option,  with  the  valve  position  pos  and  conductance  factor  cv  specified,  the  fraction  of  inlet 
pressure  pf  representing  the  pressure  drop  across  the  value  is  found  by  solving  the  equation 

m=cv  pos  (\-pfl3.0)  'Ippupf 

where  m  is  the  inlet  mass  flow  rate,  /?,-*  is  the  inlet  pressure,  and  p  is  the  inlet  density.  In  the  second  option  pf 
is  directly  input  and  the  above  equation  is  solved  for  the  valve  position  assuming  a  conductance  factor  of  one. 
In  either  ease  the  exit  pressure  is  then  determined  from 


P=Pu~Pf  Pi* 

and  the  other  state  values  arc  determined  with  a  call  to  prop  with  the  inlet  enthalpy  as  input. 
The  parameters  to  the  model  are 


pf- 

ratio  of  the  pressure  drop  to  the  inlet  pressure  (0.01).  Input 

option  - 

flag  specifying  direct  input  of  pf  (option  equal  to  two)  or  input 
tancc  (option  equal  to  one)  (2).  Input. 

of  valve  position  and  conduc 

cv  - 

valve  conductance  value.  Input. 

pos  - 

valve  position,  treated  as  an  number  between  zero  and  one  (1.0). 

Input 

dp- 

pressure  drop  through  the  valve  (atm).  Output. 

fl  - 

exit  flow  from  the  value.  Output 

If  pf  is  input  directly,  then  pos  is  an  output  actually  representing  the  product  of  a  valve  conductance  and  a  valve 
position. 

4.3.13.  Motor  (mot)  model 

The  motor  models  an  additional  supply  of  power  to  a  shaft  flow.  The  model  requires  one  shfttypc  flow  from  the 
shfts  stack  as  input  and  puts  one  shfttypc  flow  back  onto  that  stack  on  output. 

The  model  has  several  different  options,  as  specified  by  the  parameter,  option.  If  option  is  set  to  "zero", 
the  motor  will  add  to  the  input  shaft  flow  power  exactly  the  correct  amount  necessary  to  produce  a  zero  shaft 
power  at  this  point  within  the  shaft  flow.  If  the  option  is  specified  as  "level",  the  model  will  add  power  to  the 
shaft  flow  only  if  the  current  shaft  flow  power  is  less  than  some  specified  power  level,  Power o.  In  this  ease,  the 
power  added  will  be  the  minimum  of  Power0  or  the  amount  of  power  necessary  to  give  the  shaft  flow  a  power 
level  of  Powers  In  other  words,  the  motor  will  attempt  to  level  the  shaft  power  to  Power0  at  this  point  in  the 
shaft  flow  path.  Finally  if  the  option  is  set  to  something  other  than  "zero"  or  "level",  the  motor  will  simple  sup¬ 
ply  to  the  shaft  flow  the  specified  power. 

The  parameters  of  the  model  are  as  follows, 
option  -  character  string  representing  the  option  as  discussed  above  ("").  Input, 

inertia  -  the  moment  of  inertia  for  the  motor  (0.1  kg  m2).  Input 

power  -  the  specified  input  power  level  if  option  is  not  specified  as  "zero"  or  "level"  (w).  Input  when 

option  is  not  "zero"  or  "level",  output  otherwise. 
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powcrO  -  specified  Power 0  value  as  discussed  above  (le4  w).  Input  when  option  has  been  set  to  "level", 

shftf  -  exit  shaft  flow  from  the  model.  Output 


4.3.14.  Generator  (gen)  model 

The  generator  extracts  power  from  a  shaft  flow  in  an  attempt  to  model  an  electrical  generator.  This  model  is 
only  a  very  crude  representation  of  such  a  generator.  The  model  has  the  calculational  function  c  which  requires 
one  input  shfttype  flow  from  the  shfts  stack  and  puts  one  such  flow  back  onto  that  stack. 


The  model  has  two  options  controlled  using  the  stat  parameter.  When  stat  is  zero,  the  power  required  and 
extracted  from  the  shaft  is  calculated  as 


Pow=-Powralld 


I1* 

rpm 

rpirifaitj 

4 


where  Powraltd  is  some  design  point  rated  power  level  and  rpmmUd  is  the  rpm  at  this  rated  power  level.  When 
stat  is  one,  the  power  required  is  assumed  equal  to  the  shaft  power  at  this  point  in  the  flow  path. 

The  model  parameters  arc  as  follows. 

inertia  -  polar  moment  of  inertia  for  the  generator  (0.2  kg  m2).  Input 

rat_rpm  -  rated  rpm  (17800  rpm).  Input. 

rat_pow  -  rated  power  (40c6  w).  Input. 

power  -  required  power  (w).  Output.  Negative  quantities  represent  power  consumed, 

stat  -  design  point  or  off-design  point  flag  as  discussed  above  (0).  Input 


4.3.15.  Controller  (cntl)  model 

The  controller  models  a  proportional-integral-dcrivativc  (PID)  controller.  This  model  requires  no  input  flows 
and  generates  no  output  flows.  The  controlling  variable  var  is  determined  by  the  following  equation. 

var  =var  0+  k  (tp  e + —  Je  +  td —) 

where  e  represents  the  error  between  the  value  of  the  variable  to  be  controlled  and  some  specified  desired  value, 
var0  represents  a  set  point  value  of  var  at  zero  error,  and  k ,  tp ,  q ,  and  td  represent  adjustable  parameters  of  the 
controller.  Note,  if  t,  is  specified  as  0,  then  the  integral  term  is  not  include.  Likewise  if  td  is  specified  as  0, 
then  the  derivative  term  will  be  zero.  Thus,  the  controller  also  handles  proportional,  proportional-integral, 
integral,  integral-derivative,  etc.  type  of  controllers.  However,  to  actually,  make  use  of  the  derivative  type  of 
controllers,  one  must  be  able  to  accurately  calculate  the  derivative  of  the  error.  For  GPS  usage,  this  usually 
means  only  those  variables  that  are  state  values  of  differential  equations  for  which  the  derivatives  are  known  can 
be  used  in  derivative  controllers. 

Since  the  cntl  model  changes  the  controlling  variable,  the  cntl  model  could  cause  problems  in  iterative  sta 
task  loop  for  dynamic  problems.  The  controlling  variable’s  changing  value  means  that  the  constraints  in  this 
loop  might  not  be  a  true  function  of  the  specified  parameters  that  are  being  varied  within  the  loop.  To  eliminate 
this  problem,  the  cntl  model  has  an  option,  controlled  with  the  stat  parameter,  for  putting  die  controlling  param¬ 
eter  within  a  vary-cons  funedon  pair  internally  within  the  model.  Thus,  when  stat  is  zero,  a  temporary  value 
representing  the  value  that  the  controlling  variable  is  to  obtain  based  on  the  above  equadon  is  calculated,  var  is 
then  varied  within  the  same  sta  task  loop  as  the  other  parameters  undl  it  becomes  equal  to  this  temporary  value. 
This  permits  the  following  method  for  using  the  end  model.  Within  the  inner  loop  of  die  dynamic  problem,  die 
actually  controlling  variable  is  defined  to  be  equal  to  var  before  the  model  in  which  die  controlling  variable  is 
found.  After  the  error  is  calculated,  the  end  mode!  can  then  be  called. 

The  parameters  to  the  model  are  as  follows. 

stat  -  flag,  when  zero,  turns  on  the  implicit  calculadons  of  var  using  die  vary-cons  functions,  and 

when  one  turns  off  these  implicit  calculadons  (0).  Input.  Note  that  when  stat  is  one,  the 
model  will  directly  return  the  value  of  var. 
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var  - 

the  controlling  parameter  value.  Input  on  initializing  calls,  output  thereafter. 

ti  - 

/;  value  (0.0).  Input. 

tp- 

tp  value  (0.0).  InpuL 

td- 

td  value  (1.0).  Input 

k- 

k  value  (1.0).  Input 

err  - 

e  value.  Input. 

derr  - 

derivative  of  e  (0.0).  Input 

cntlO  - 

set  point  value  of  var  when  e  is  zero  (0.0).  Input. 

cntlv  - 

calculated  value  of  var.  When  stat  is  equal  to  one,  var  is  simply  set  equal  to  cntlv.  When  stat 
is  zero,  var  and  cntlv  arc  made  equal  using  a  vary-cons  loop. 

ub  - 

approximate  upper  bound  on  var  when  used  in  the  vary-cons  functions  (1.0). 

Input. 

lb- 

approximate  lower  bound  on  var  when  used  in  the  vary-cons  functions  (1.0). 

Input. 

In  order  to  prevent  hitting  either  the  upper  or  lower  bounds  within  the  controller  vary-cons  loop  iterations 
the  actual  upper  and  lower  bounds  used  are  slightly  adjusted  from  those  that  are  specified  by  the  user.  Both 
bounds  arc  extended  by  one  tenth  the  distance  between  the  specified  bounds  and  the  calculated  value  of  the  con¬ 
trolling  parameter  is  truncated  at  the  original  user  specified  bounds. 

4.4.  Dynamic  system  tasks 

As  mentioned  within  the  introduction  to  the  dynamic  models,  many  of  the  models  make  use  of  the  task  func¬ 
tions  for  integrating  the  differential  equations  of  the  models  and  also  for  representing  the  mass/momentum 
exchanges  within  the  system.  Each  of  these  will  require  the  user  to  include  within  the  driver  coding  a  task 
loop.  In  the  case  of  the  differential  equations,  the  task  name  used  by  all  of  the  models  is  denoted  as  dyn,  thus, 
the  driver  code  requires  a  dyn  task  loop.  This  also  means  that  the  time  variable  is  denoted  as  dyn.time. 

In  the  case  of  the  mass  and  momentum  exchanges,  the  models  use  the  task  named  sta.  This  task  should 
be  set  up  within  the  driver  coding  nested  within  the  dyn  task.  Since  both  of  these  tasks  arc  always  required 
when  using  the  dynamic  models,  both  arc  defined  within  the  cinit  function  and  thus,  do  not  need  to  be  explicitly 
allocated  using  the  cncw  operator.  A  generic  representation  of  the  dynamic  inputs  would  look  something  like 
the  following. 

cinit 

"model  allocations,  parameter  specifications,  etc.  using  cnew" 

0  toutjncrcment  t_final 
(/dyn.tout  cxch  def 
(dyn.c) 

({sta.c} 

( 

"model  calls,  parameter  specifications,  user  define 
vary  and  cons,  etc." 

} 

while 

} 

while 

gass.print  mods.print 
"additional  output" 

} 

for 


Within  the  sta  task  loop  the  actual  number  of  vary  and  cons  function  calls  should  balance  with  one  vari¬ 
able  for  each  constraint  Thus,  the  user  of  the  dynamic  models  must  keep  track  of  which  models  arc  using  a 
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vary  function  and  which  arc  using  a  cons  function.  This  is  actually  not  difficult,  since  each  time  a  new  flow 
path  is  generated,  a  vary  function  is  used  and  each  time  a  flow  path  is  terminated  a  cons  function  is  used. 
Thus,  vary’s  are  use  within  the  gas  and  sp  functions  and  cons’s  are  used  within  the  mx  and  exnz  functions. 
Generally,  the  parameters  that  arc  varied  adjust  the  mass  flow  rates  along  the  flow  path  (m  in  the  gas  model  and 
sr  in  the  sp  model).  The  constraints  arc  then  equations  that  would  define  what  the  mass  flow  would  be  (such  as 
choked  flow  within  the  exnz  model).  At  times  it  may  be  necessary  to  add  within  the  driver  coding  additional 
vary  and  cons  function  calls  within  the  sta  task  loop.  This  might  occur  if  a  model’s  stat  parameter  is  set  to 
one,  implying  that  the  model’s  vary  or  cons  function  is  not  called.  There  really  is  an  endless  number  of  possi¬ 
bilities  and  the  user  must  be  clear  as  to  what  the  problem  is  that  is  being  set  up  with  the  input 

4.5.  Dynamic  example  one 

For  an  example  of  the  use  of  the  dynamic  system  components  we  will  consider  a  dynamic  analysis  of  a  space 
nuclear  rocket  system.  The  model  parameter  values  for  this  example  arc  not  meant  to  correspond  to  any  partic¬ 
ular  system.  The  example  is  only  for  illustrative  purposes  in  showing  the  type  of  thinking  necessary  to  use  the 
GPS  code  for  dynamic  problems.  Figure  2,  shows  a  block  diagram  for  the  system.  The  main  thruster  nozzle  is 
exnz_I,  although  part  of  the  flow  is  diverted  to  drive  the  turbo  pump,  pump_tp,  and  is  exhausted  through  a 
second  nozzle,  exnz_tp.  Several  valves  arc  provided  for  system  control,  a  tank  shut-off  valve,  valv_tsov,  a 
pump  shut-off  valve,  valv_psov,  a  temperature  control  valve,  valv_tcv,  and  a  turbine  speed  control  valve, 
valv_scv. 
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In  analyzing  such  a  system,  the  first  step  is  to  develop  a  full  power  design  point.  This  will  be  used  to 
determine  pipe  sizings  for  reasonable  flow  velocities,  exhaust  areas  for  the  nozzles,  and  valve  positions.  Note, 
that  since  this  system  configuration  has  one  flow  initiator  and  two  splitters,  there  arc  three  automatically  imposed 
parameter  variations.  Also,  since  there  are  two  exhaust  nozzles  and  one  mixer  there  are  three  automatically 
imposed  constraints.  As  mentioned  within  the  section  on  the  models  aMvc,  many  of  the  models  have  a  special 
steady-state  option  for  turning  these  automatically  imposed  variations  and  constraints  off.  This  is  done  by  speci¬ 
fying  the  model’s  stat  variable  to  one.  With  this  option  specified  in  the  exhaust  nozzles,  the  constraints  on  mass 
flow  rates  (calculated  from  the  flow  areas)  are  not  used.  Instead,  the  mass  flow  rates  are  treated  as  the  knowns 
and  the  flow  areas  are  calculated.  This  permits  one  to  determine  the  design  flow  areas  by  specifying  the  design 
point  flow  rates.  In  order  to  specify  this  design  point  flow  rate,  the  stat  option  will  need  to  be  turned  on  (i.e.  set 
to  one)  in  the  gas  model  representing  the  hydrogen  tank.  This  will  prevent  the  automatic  iterations  over  the 
mass  flow  rate.  Note  that  turning  on  the  stat  option  within  both  exhaust  nozzles  we  have  turned  off  two  automat¬ 
ically  imposed  constraints  and  by  turning  on  the  stat  option  in  the  tank  model  we  have  turned  off  one  automati¬ 
cally  imposed  parameter  variation.  Thus,  in  order  to  rebalance  the  number  of  constraints  and  parameters  being 
varied,  one  additional  constraint  needs  to  be  imposed  or  another  of  the  parameter  variations  needs  to  be 
removed.  Since  at  die  design  point  there  are  several  other  constraints  that  need  to  be  imposed  we  will  add  an 
additional  constraint. 

First,  at  an  equilibrium  design  point,  the  power  required  by  the  pump  should  be  constrained  to  exaedy 
match  the  shaft  power  generated  by  the  gas  turbine.  This  additional  constraint  will  rebalance  the  number  of 
constraints  and  the  number  of  parameters  being  varied.  However,  as  an  additional  constraint  on  the  system  we 
impose  a  design  value  on  the  gas  turbine  inlet  temperature  of  950K.  This  constraint  will  be  met  by  varying  the 
temperature  control  valve  pressure  drop.  By  varying  this  pressure  drop,  a  greater  or  lesser  amount  of  cold  gas 
flow  will  be  directed  to  the  mixer,  thus,  affeedng  the  downstream  temperature. 

The  complete  input  necessary  to  determine  the  full  power  design  point  is  as  follows, 
emit 

[/gas  /gas_h2  /id  "THR-tH2"  /t  20  /p  3.0  /m  1.0  /diam  .05  /stat  1  ]  cncw 

[/valv  /vaIv_tsov  /pf  0.02  ]  cncw 

l/pi  /pi_l  /rat_m  1.0  /rat_pf  0.0002  /diam  .05  ]  cncw 

[/pump  /purnpjp  /rat_rpm  60000.  /rat_dp  84.0  /rat_m  1.0  ]  cncw 

[/valv  /valv_psov  /pf  0.02  ]  cncw 

[/pi  /pi_2  /rat_m  1.0  /rat_pf  0.0001  /diam  .05  ]  cnew 

[/ht  /ht_r  /t#l  80.  ]  cncw 

f/sp  /sp_l  /sr  0.05  /diam#0  0.05  ]  cnew 

[/pi  /pi_3  /rat_m  1.0  /rat_pf  0.0001  /diam  .03  ]  cnew 

[/rcac  /rcac_l  /tcool  3000.  /diam  .05  /rat_m  1.0  /rat_pf  0.05  /ucool  le5  ]  cnew 

[/sp  /sp_2  /sr  0.02  /diam#0  0.05  /diam#l  0.05  ]  cnew 

[/pi  /pi_4  /rat_m  .03  /rat_pf  0.0001  /diam  .05  ]  cncw 

[/cxnz  /cxnz_l  /aexp  15c-3  /mach  3.5  /stat  1  ]  cncw 

[/valv  /valvjcv  /pf  0.05276954  ]  cncw 

[/pi  /pi_5  /rat_m  .08  /rat_pf  0.0001  /diam  .01  ]  cncw 

[/mx  /mx_l  /p  0.92  /diam  0.02  ]  cncw 

[/pi  /pi_6  /rat_m  .11  /rat_pf  0.0001  /diam  .02  }  cncw 

[/valv  /valv_scv  /pf  0.5  ]  cnew 

[/pi  /pi_7  /rat_m  .11  /rat_pf  0.0001  /diam  .02  ]  cncw 

f/gt  /gt_tp  /rat_pr  1.5  /inertia  0.2  /stat  1  /rat_eff  .86282  ]  cncw 

[/exnz  /cxnzjp  /diam  lc-2  /stat  1  ]  cnew 

[/shft  /shft_l  /rpm  60000  ]  cnew 

pump_tp.in  gt_tp.in 

/sta.prt  2  def  /sta.acc  lc-3  def 
(sta.c) 

{/valvjcv.pf  valv_tcv.pf  0.02  0.17  vary 


58 


gas_h2.c  valvjsov.c  pi_l.c  shft_l.c 
pumpjp.c  valv_psov.c  pi_2.c  ht_r.c  sp_l.c 
pi_3.c  reac_l.c  sp_2.c  cxnz_l.c 

sp_l.s  valv_tcv.c  pi_5.c  mx_l.s  sp_2.s  pi_4.c  mx_l.c  pi_6.c 
valv_scv.c  pi_7.c  gt_tp.c  cxnzjp.c  shft_l.cnd 
/sp_l.sr  (pi_7.fl.t-950.)  cons 
/sp  2.sr  (gt  tp.power+pump  tp.powcr)  cons 
) 

while 

gass.print  mods.print 
/all  cdcl 


The  model  names  used  in  this  input  correspond  to  those  shown  in  Figure  2.  In  order  to  simply  the  specification 
of  the  system,  many  of  the  model  parameters  arc  left  unspecified  and  thus,  will  assume  their  default  values. 
After  the  model  parameter  specifications,  the  performance  maps  for  the  pump  and  gas  turbine  arc  obtained  using 
the  line 

pumpjp.in  gtjp.in 

The  sta  task  loop  is  then  entered,  where  the  three  variables  used  to  control  the  three  constraints  arc  varied. 
Note,  that  as  discussed  above,  only  the  temperature  control  valve,  valv_tcv,  is  explicitly  varied.  The  other  vari¬ 
ables  being  varied  arc  defined  within  the  splitters.  The  system  configuration  is  then  coded  by  calling  the  models 
in  the  appropriate  order  as  defined  by  Figure  2.  The  resulting  model  calls  representing  the  system  should  be  per¬ 
fectly  clear.  Finally  the  constraints  are  evaluated  and  the  loop  terminated.  Here  only  two  of  the  three  constraints 
arc  explicitly  written  down.  The  third  one  is  defined  within  the  mixer  (since  its  stat  parameter  was  left  as  zero). 
The  last  line  then  calls  the  gass  print  function  and  the  mods  print  function  to  obtain  the  output 

The  resulting  output,  from  this  code  is  shown  in  Appendix  D.  This  Appendix  first  shows  the  iterations  per¬ 
formed  by  the  equation  solver  for  the  sta  task  necessary  to  establish  the  three  constraints.  This  output  is  exactly 
as  with  any  equation  solver  task  and  was  explained  within  the  section  on  the  task  examples.  The  rest  of  the  out¬ 
put  is  obtained  from  the  gass.print  and  mods.print  functions,  and  is  also  the  same  as  with  the  steady-state 
examples. 

Now  consider  a  start-up  run  of  this  same  propulsion  system.  A  similar  set  of  inputs  as  those  in  design  run 
will  be  needed  but  with  some  minor  changes.  The  final  input  is  as  follows. 

cinit 

[/gas  /gas_h2  /id  "THR-tH2"  /t  20  /p  3.0  /m  0.3  /diam  .05  ]  cnew 
[/valv  /valvjsov  /pf  0.02  ]  cnew 
[/pi  /pLl  /rat_m  1.0  /rat_pf  0.0002  /diam  .05  ]  cnew 
[/pump  /pump_tp  /rat_rprn  60000.  /rat_dp  84.0 
/rat_m  1.0  /inertia  0.01  ]  cnew 
[/valv  /vaIv_psov  /pf  0.02  ]  cnew 
[/pi  /pi_2  /rat_m  1.0  /rat_pf  0.0001  /diam  .05 )  cnew 
C/ht  /ht_r  /t#l  80  ]  cnew 
[/sp  /sp_l  /sr  0.02  /diam SO  0.05  ]  cnew 
(/pi  /pi_3  /rat_m  1.0  /rat_pf  0.0001  /diam  .03  ]  cnew 
[/rcac  /reac_l  /tcool  100.  /tfucl  300. 

/diam  .05  /rat_m  1.0  /rat_pf  0.05 
/ucool  1.0e4  /mfucl  200.  ]  cnew 
(/sp  /sp_2  /sr  0.01  /diamSO  0.05  /diam#)  0.05  ]  cnew 
(/pi  /pi_4  /rat_m  .03  /rat_pf  0.0001  /diam  .05  ]  cnew 
f/exnz  /cxnz_l  /aexp  1.5e-02  /mach  3.7 /diam  2.6459e-02  ]  cnew 
[/valv  /valv_tcv  /pf  lc-2  ]  cnew 
(/pi  /pi_5  /rat_m  .08  /rat_pf  0.0001  /diam  .01  )  cnew 
[/mx  /mx_l  /diam  0.02  ]  cnew 
[/pi  /pi _6  /ratjn  .11  /rat_pf  0.000 1  /diam  .02  ]  cnew 
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[/valv  /valv_scv  /pf  0.02  ]  cnew 

[/pi  /pi_7  /rat_m  .11  /rat_pf  0.0001  /diam  .02  ]  cncw 

f/gt  /gt_tp  /rat_pr  1.5  /inertia  0.02/rat_cff  .86282 

/rat_cmass  9.8004e-02  /rat_cspccd  1.9467c+03  ]  cnew 
[/cxnz  /exnz_tp  /diam  1.2760e-02  ]  cncw 
[/shit  /shft_l  /ipm  5000  ]  cncw 

[/end  /end  1  /var  0.02  /cndO  0.5  /lb  0.02  /ub  0.98  /tp  1.0  ]  cnew 
/tl  0.0  def 

pump_tp.in  gtjp.in 

/sta.prt  0  def  /sta.acc  lc-3  def  /sta.del  (-le-3)  def  /sta.maxit  10  def 
/dy.t.pn  2  def 

0.0  1.0  30.0 
{/dyn.lout  cxch  def 
{dyn.c} 

{ 

[sta.cj 

[dyn.ume  15.0  It 

{/rcac_l .power  (rcac  I.power0+42.442c6*dyn.timc/15.0)  def} 
if 

/valv_tcv.pf  valv_tcv.pf  0.001  0.98  vary 
/valv_scv.pf  cnd_l.var  def 
gas_h2.c  valv_tsov.c  pi_l.c  shft_l.c 
pumpjp.c  valv_psov.c  pi_2.c  ht_r.c  sp_l.c 
pi_3.c  rcac_l.c  sp_2.c  exnz_l.c 

sp_l.s  valv_tcv.c  pi_5.c  mx_l.s  sp_2.s  pi_4.c  mx_l.c  pi_6.c 

valv_scv.c  pi_7.c  gt_tp.c  exnz  tp.c  shft  l.cnd 

/tl  (0.9*rcac_l.fl.t)  950  gt  {950.0}  {(0.9*rcac_l.fl.t)]  ifclscdcf 

/sp_2.sr  (pi_7.fl.t-tl)  cons 

/cnd_l.crr  ((shft_l.rpm-60000)/20000)  def 

cntl_l.c 

} 

while 

} 

while 

gass.print  mods.print 

} 

for 

/all  cdcl 

First,  the  slat  opdon  for  all  models  should  be  turned  off  (or  removed  from  the  input).  Secondly,  the  critical 
areas  (or  diameters)  in  the  exhaust  nozzles  as  calculated  in  the  design  run  should  be  added  as  inputs.  These 
include  cxnzl.diam,  exnzl.acxp,  and  exnz_tp.diam.  The  design  point  calculated  values  of  the  rated  corrected 
mass  and  corrected  speed  for  the  gt_tp  model  should  also  be  added  as  inputs.  These  parameter  values  basically 
supply  the  design  point  sizing  information  necessary  for  those  models  that  are  based  on  modeling  that  is  relative 
to  the  design  point. 

Several  other  model  parameters  now  need  to  be  changed  to  reflect  initial  values  for  the  start-up  ran.  In 
particular,  the  reactor  gas  exit  temperature  will  need  to  be  assigned  some  nominal  starting  value,  say  100K. 
Although  it  is  possible  to  let  the  code  calculate  an  equilibrium  fuel  temperature  corresponding  to  this  specified 
gas  exit  temperature,  here  an  initial  300K  fuel  temperature  will  be  imposed.  An  actual  system  will  probably 
have  some  pre-flow  power  level  resulting  in  some  temperature  somewhat  higher  than  that  of  the  incoming  flow. 
The  inlet  mass  flow  rate  defined  by  gasl.m  should  also  be  lowered  from  the  design  point  value.  This  flow  rate 
will  actually  be  calculated  by  the  code,  however,  a  smaller  value,  say  0.3,  will  reflect  a  more  reasonable  starting 
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value  for  the  iterations.  The  turbo  pump  shaft  speed,  defined  by  shftl.rpm,  should  also  be  set  to  some  starting 
value.  In  the  run  below,  this  was  set  at  5000  rpm.  Although,  this  could  be  set  lower,  in  general,  if  the  rpm  is 
set  to  low,  insufficient  pressure  is  developed  by  the  pump,  and  depending  on  valve  positions,  temperatures,  etc, 
the  flow  velocities  may  become  extremely  large  as  the  system  is  initially  starting.  The  flow  might  actually 
become  momentarily  choked  at  places  that  the  code  was  not  expecting.  A  lumped  component  model  of  a  sys¬ 
tem  can  only  handle  choked  flow  where  the  model  developer  intends  for  it  to  occur. 

Next,  the  integration  loop  needs  to  be  added  around  the  sta  loop.  In  the  run  below,  the  integrations  arc 
defined  from  zero  to  thirty  second,  with  intermediate  output  requested  at  every  second. 

Finally,  the  control  strategy  for  the  system  needs  to  be  considered.  This  usually  refers  to  the  rate  of  reac¬ 
tor  power  ramp-up  and  the  rate  of  opening  or  closing  of  valves.  For  this  system,  the  reactor  power  ramp-up  will 
be  done  linearly  from  some  nominal  power  level,  determined  by  the  initial  gas  temperature  rise  and  defined  in 
the  variable  rcacl.powcrO,  to  the  design  value  of  42.442  MW  (plus  the  initial  nominal  value)  in  a  time  frame  of 
fifteen  seconds.  The  tank  shut-off  valve  and  the  pump  shut-off  valve  will  be  instantaneously  ojicncd  at  time 
zero.  The  same  design  point  constraint  on  the  inlet  gas  turbine  temperature  will  be  imposed,  only  now,  rather 
than  fixing  this  temperature  at  950K,  it  will  be  constrained  to  be  90%  of  the  reactor  outlet  temperature  up  to 
950K  and  constant  thereafter.  This  is  done  within  the  inputs  by  defining  the  variable  tl  to  be  this  constraining 
temperature  value.  Note,  that  since  the  temperature  out  of  the  mixer  is  an  instantaneous  function  of  its  inlet 
flow  conditions,  this  gas  temperature  constraint  can  be  meant  by  using  the  vary-cons  operators  within  the  sta 
loop.  In  a  real  system,  some  controller  would  be  needed  to  actually  sense  the  temperature  and  gradually  adjust 
the  temperature  control  valve.  Finally,  to  gain  some  control  on  the  speed  control  valve,  a  proportional  con¬ 
troller,  cntll,  is  added.  Within  the  sta  task  loop  the  variable  being  controlled,  valv_scv.pf,  is  assigned  the  value 
cntll.var.  Upper  and  lower  bounds  are  also  specified  for  this  controlled  variable,  as  well  as  a  set  point  value  of 
0.5,  corresponding  to  the  design  point  value  of  valv_scv.pf.  The  value  of  the  sensor  error  (i.c.  the  difference 
between  the  variable  being  sensed  and  its  desired  value)  is  calculated  within  the  sta  loop  by  the  line 

/cntll.crr  ((shftl.rpm-60000)/20000)  def 

Here,  the  error  will  be  zero  at  60000  rpm,  at  which  point  the  controller  will  assign  valv_scv.pf  the  value  of  the 
set  point.  The  additional  dividing  factor  of  20000  was  used  instead  of  adjusting  the  controller's  gain  parameter, 
k.  Note,  this  is  only  a  very  crude  representation  of  a  controller  for  the  speed  control  valve. 

Some  of  the  resulting  computer  run  output  is  shown  in  Appendix  E.  Due  to  the  length  of  the  entire  output 
only  the  zero,  ten,  twenty,  and  thirty  second  outputs  are  shown.  This  output  clearly  shows  dial  considerably 
more  effort  needs  to  go  into  the  system  control  strategy  even  for  this  very  simple  example.  The  reactor  fuel 
temperature  using  this  simple  ramp-up  has  risen  to  3343K  while  the  gas  temperature  has  reached  only  U18K. 
Also,  the  pressure  levels  arc  still  a  long  way  from  the  design  point 


CHAPTER  5 


Thermionic  Power  System  Mode!  Classes 


5.1.  Introduction 

In  this  chapter  wc  discuss  the  details  of  the  component  models  that  are  used  to  analysis  thermionic  power  sys¬ 
tems.  These  models  were  assembled  only  as  a  very  simple  first  approximation  from  existing  models  furnished 
by  the  Air  Force.  Ultimately,  these  models  will  probably  be  replaced  and  possibly  moved  into  the  steady-state 
and/or  dynamic  model  class  library.  At  present,  these  models  include  the  following. 


reac  - 

reactor  model 

ti  - 

thermionic  converter 

rad  - 

thermal  radiator 

sp- 

power  flow  splitter 

rcs  - 

electrical  resistor 

be  - 

boost  converter 

bus  - 

electrical  bus 

mass  - 

mass  calculations 

5.2.  Thermionic  Model  Flow  Classes 

The  models  used  in  this  collection  don’t  make  use  of  any  fluid  flow  but  instead  make  use  of  a  power  flow.  In 
order  to  keep  the  models  as  simple  as  possible  for  this  first  approximation,  only  one  type  of  flow  class  is  used 
and  is  simply  denoted  as  flowtype,  Flowtype  is  used  to  transmit  both  thermal  energy  flows  and  electrical  flows. 
At  present,  flowtype  consists  of  the  following  variables. 

pow  -  represents  the  power  being  transmitted  by  the  flow  in  watts. 

v  -  represents  the  voltage  level  in  volts  relative  to  ground  for  electrical  flows.  Note  that  for  ther¬ 

mal  flows  v  is  not  used. 

i  -  represents  the  current  in  amps  for  electrical  flows.  For  thermal  flows,  i  is  not  used. 

At  present,  the  thermionic  models  are  so  simple  that  no  special  model  is  used  to  generate  a  flowtype  flow. 
Instead  the  reac  model  is  used  instead.  Note  that  as  more  modeling  details  arc  added  to  the  thermionic  model 
classes  the  flow  structures  will  also  probably  need  to  be  changed.  The  flowtype  flows  are,  like  all  flows,  placed 
on  a  stack,  here  denoted  as  flows,  flows  can  be  used  to  print  tables  of  the  flows  with  flows.print. 


5.3.  Thermionic  models 

In  this  section  wc  present  the  details  of  the  thermionic  power  system  models  that  are  presently  available.  These 
models  arc  similar  to  models  supplied  by  the  Air  Force  with  some  rearranging  so  that  they  would  fit  within  the 
GPS  structure.  Most  of  the  modeling  is  composed  of  simple  correlations,  some  of  which  need  to  be  replaced 
with  more  accurate  expressions. 


Since  the  mass  of  the  components  is  an  important  consideration  in  the  projected  applications  of  these  ther¬ 
mionic  systems,  a  masstype  class  was  also  included  with  the  models.  This  masstype  class  is  used  to  store  the 
various  component  masses  and,  in  some  cases,  sub-component  mass.  The  masstype  structures  are  stored  on  the 


stack  masss,  which  is  then  accessed  by  the  mass  model  to  calculate  the  total  system  mass.  Masstype,  at 
present,  consists  of  only  the  single  variable, 


mass  -  representing  the  mass  of  the  corresponding  object  in  kg. 
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5.3.1.  Reactor  (reac)  model 

The  reactor  model  is  used  to  initiate  two  flows.  The  first  is  the  flow  utilized  by  the  thermionic  converter  and  the 
second  is  the  waste  heat  flow.  The  split  of  the  total  reactor  generated  power  between  these  two  flows  is  given 
by  an  input  efficiency.  Technically,  this  efficiency  represents  the  thermionic  conversion  efficiency,  but  is 
included  within  this  model  rather  than  the  thermionic  model  so  that  upstream  model  references  are  avoided. 

The  main  calculations  are  performed  within  the  model’s  c  function  and  consist  mainly  cf  mass  and  sizing 
calculations.  The  following  calculations  are  performed. 

Powy*t\Pow 
PoWf*(l-Vl)  Pow 
rre=0.13  104SPoh'S2x104 

=0.20  2x1O4</,0h><4x1O4 
Ken  =2.8 \PoW  |40.2 1 
me0n  =24.2Pow  i+23.5 


mu= 100 


w„=15.8/,0K'1+149  d„p£l5.0 
=2l.4ftWi+262  15*/,v£10.0 
=26.9Pow  i+374  10>d„„ 
r„=1.56P<w,+0.91 
V„=mnh„(rl+r*+r„rrc) 
lboom~dsep'~^ 

Mboom^Ptxxm  ( boom 

where,  Pow  is  the  input  reactor  power  level,  Pow\  is  the  power  used  in  the  thermionic  component,  Pow2  is  the 
rejected  waste  heat,  rn  is  the  reactor  core  radius,  r„  is  the  radiation  shield  radius,  hcort  is  the  reactor  core 
height,  mcort  is  the  mass  of  die  core,  msl  is  the  mass  of  the  safely  systems,  m„  is  the  mass  of  the  radiation 
shield,  m/m,m  is  the  mass  of  the  boom,  V„  is  the  volume  of  the  radiation  shield,  „nd  4«,m  is  die  length  of  die 
boom,  and  dstp  is  the  separadon  distance  between  the  shield  and  core.  The  c  funedon  also  outputs  to  the  (low 
stack  the  flow  that  is  to  be  sent  to  the  thermionic  converter.  The  model’s  s  funedon  can  be  called  to  obtain  the 
waste  heat  flow. 

The  model  has  the  following  variables. 


pow  - 

reactor  power  level  (le6  watts).  Input. 

eff- 

thermionic  conversion  efficiency  (0.13).  Input. 

sep  - 

separadon  distance  dup  (10  m).  Input 

radius  - 

core  radius  rrc  (m).  Output. 

height  - 

core  height  hn  (m).  Output. 

rhoboom  - 

boom  density  (10.0  kg/m).  Input. 

lboom  - 

length  of  the  boom  (m).  Output. 
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radiusrs  - 

radius  of  the  shield  rn  (m).  Output 

heightrs  - 

height  of  the  shield  hrs  (0.37  m).  Input. 

volrs  - 

volume  of  the  shield  Vrs  (m3).  Output 

mcore  - 

mass  of  the  core  mcort  (kg).  Output. 

mss  - 

mass  of  the  safety  systems  mu  (kg).  Output 

mrs  - 

mass  of  the  radiation  shield  m„  (kg).  Output. 

mboom  - 

mass  of  the  boom  m(wom  (kg).  Output. 

fl  - 

primary  flow  to  the  converter.  Output 

fls- 

secondary  or  waste  heat  flow.  Output. 

Note  that  each  of  the  mass  variables  is  really  one  of  niasstype  and  thus,  for  example,  mcore  would  be  referred 
to  as  mcorc.mass  within  the  GPS  inputs.  Similarly,  both  of  the  output  flows  are  of  flowtype.  Thus,  the  output 
power  to  the  converter  would  be  referenced  as  fl.pow. 

5.3.2.  Thermionic  Converter  (ti)  model 

The  thermionic  converter  model  takes  a  power  flow  and  partitions  it  into  an  I-V  character.  The  model’s  calcula- 
tional  function  c  requires  one  flow  on  the  flows  stack  and  puts  one  flow  back  onto  that  stack.  The  following 
calculations  are  performed. 

/vconv 
i=Powlv 
^cp  =i  Hconv 

m=13.15Pow-3.5 

where  v  is  the  specified  output  voltage  from  all  converters,  v„w  is  the  individual  converter  output  voltage,  Pow 
is  the  input  power,  i  is  the  output  current,  icom  is  the  individual  converter  output  current,  na  and  ncp  are  the 
number  of  converters  in  series  and  parallel,  respectively,  and  m  is  the  total  converter  mass. 

The  model  has  the  following  variables, 
v  -  total  output  converter  voltage  (250  V).  Input, 

vconv  -  individual  converter  output  voltage  vC0HV  (0.67  V).  Input 

iconv  -  individual  converter  output  current  iC0l „  (62.0  amps).  Input, 

ncs  -  number  of  converters  in  series  na.  Output 

ncp  -  number  of  converters  in  parallel  ncp .  Output, 

m  -  total  mass  of  the  converter  (kg).  Output, 

fl  -  output  electrical  flow  from  the  converter.  Output. 

5.3.3.  Radiator  (rad)  model 

Rad  models  a  thermal  radiator.  The  model  requires  one  flow  from  the  flow  stack  and  puts  one  flow  back  onto 
the  stack.  The  calculations  arc  as  follows. 

A  _  Pow 

tt(T*-Ts4paC') 


m=pA 

where  Pow  is  the  input  power  (heat),  e  is  the  surface  cmissivity,  cr  is  the  Stefan-Boltzmann  constant,  A  is  the 
radiator  surface  area,  T  is  the  surface  temperature,  Tspxe  is  the  effective  space  temperature,  p  is  the  radiator 
mass  per  unit  surface  area,  and  m  is  the  total  radiator  mass. 


64 


The  model  has  the  following  variables. 


t  - 

radiator  surface  temperature  (K).  Input 

tspacc  - 

effective  space  temperature  (255K).  Input. 

rho  - 

radiator  density  per  unit  area  (44.0  kg/m  3).  Input 

c  - 

surface  cmissivity  e  (0.85).  Input 

area  - 

surface  area  (m  2).  Output. 

m  - 

radiator  mass  (kg).  Output 

fl  - 

output  flow. 

5.3.4.  Boost  Converter  (be)  model 

The  boost  converter  models  a  repartition  of  an  input  power  flow  into  new  I-V  characteristics  at  a  specified  input 
efficiency.  The  model’s  calculational  function  c  requires  one  input  flow  from  the  stack  and  puls  one  flow  back 
onto  the  stack.  The  calculations  are  as  follows. 

Pow ,  =T|  Pow 
Poww=(\-r\)  Pow 
i=Pow,lv 

where  Pow ,  Pow ,  and  Poww  arc  the  input,  electrical  output,  and  waste  heat  output  power  flows,  T|  is  the  con¬ 
verter  efficiency,  v  is  the  specified  converter  output  voltage  and  i  is  the  converter  output  current.  The  waste 
power  flow  is  obtained  by  calling  the  secondary  s  function  of  the  model. 

The  model  has  the  following  parameters, 
v  -  output  voltage  (250  V).  Input, 

eff  -  converter  efficiency  (0.95).  Input, 

fl  -  output  electrical  flow, 

fls  -  output  waste  heat  flow. 

5.3.5.  Flow  Splitter  (sp)  model 

The  flow  splitter  model  is  used  to  split  a  single  power  flow  into  two  flows  based  on  an  input  split  ratio.  For 
electrical  flows  this  split  ratio  can  be  thought  of  as  a  current  split  ratio  and  for  thermal  flows  as  a  power  split 
ratio.  The  model’s  calculational  function  c  requires  one  input  flow  and  generates  one  output  flow.  The  second 
flow  is  then  obtained  from  the  model’s  secondary  function  s.  The  calculations  are  as  follows. 

h ~sr  hn 

V2=v;„ 

*>(1- sr)iu 


V^Vin 

Powf=sr  PoWfo 
Pow  j=(l— sr  'jP  ow,n 

where  sr  is  the  split  ratio,  /,  v,  Pow  represent  the  current,  voltage,  and  power,  respectively,  and  the  subscripts, 
in,  1,  and  2  correspond  to  the  input,  and  two  output  flows. 

The  model  has  the  following  variables. 
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sp  -  split  ratio  (0.1).  Input. 

(Is  -  second  or  split  off  flow.  Output. 

11  -  remaining  flow.  Output. 

5.3.6.  Resistor  (res)  model 

The  resistor  models  an  electrical  resistance  and  hence,  an  electrical  voltage  drop.  The  model’s  calculational 
function  requires  one  flow  from  the  stack  and  outputs  one  flow  back  to  the  stack.  The  calculations  arc  as  fol¬ 
lows. 


V=V/,-J;,r 


1=1:, 


Pow=vi 

where  v1B  is  the  input  voltage,  v  is  the  output  voltage,  4,  is  the  input  current,  i  is  the  output  current,  r  is  the 
resistance,  and  Pow  is  the  output  power. 

The  model  has  die  following  variables, 
r  -  electrical  resistance  (0.0  Ohms).  Input, 

fl  -  output  flow. 

5.3.7.  Bus  (bus)  model 

The  bus  model,  at  present,  does  nothing,  i.e.  its  only  output  flow  is  exactly  as  the  input  flow. 

5.3.8.  Mass  (mass)  model 

The  mass  model  is  used  to  perform  a  global  sum  over  all  the  stored  masstype  variables  in  all  the  models.  In 
addition,  it  is  used  to  furnish  an  electrical  distribution  system  mass  and  an  instrument  and  control  system  mass. 
Both  of  these,  at  present,  arc  simply  taken  as  fixed  numbers. 

mju,=  220 


=222 

Note  that  since  this  model  requires  information  that  is  calculated  in  all  the  other  models,  it  should  only  be  called 
after  all  the  other  models  have  been  called.  The  print  function  for  the  mass  model  will  generate  a  table  of  the 
masses  of  all  the  components. 

The  model  has  the  following  variables, 
mic  -  mass  of  the  instrument  and  control  subsystem  (kg).  Output 

mdist  -  mass  of  the  electrical  distribution  subsystem  (kg).  Output, 

mtot  -  total  system  mass  (kg).  Output 


5.4.  Thermionic  System  Example 

In  this  section  we  present  a  very  simple  thermionic  power  system  example  using  GPS.  The  system  diagram  for 
the  example  is  shown  in  Figure  3.  The  example  consists  of  a  reactor  (reac_l)  driving  a  thermionic  converter 
(ti_l).  The  power  flow  from  the  converter  is  then  partially  split  off  (sp_shunt)  into  a  shunt  radiator  (rad_shunt) 
with  the  rest  of  the  power  flow  going  through  a  resistance  (resji),  a  boost  converter  (bc_l),  another  resistance 
(res_bc)  and  finally  into  the  power  bus  (bus_l).  The  reactors  waste  heat  is  then  feed  into  the  primary  radiator 
(rad_prim),  the  split  off  flow  from  sp_shunt  is  then  feed  into  the  shunt  radiator  (rad.shunt)  and  finally,  the  boost 
converters  waste  heat  is  feed  into  another  radiator  (rad_bc). 

One  system  constraint  will  also  be  imposed  and  that  is  to  produce  exactly  40  kw  at  the  bus.  The  total 
input  necessary  to  run  the  problem  is  as  follows. 
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Figure  3. 


cinit 

[/rcac  /rcac_l  /pow  I00c4]  cncw 
[/ti  /ti_l  /v  6]  cnew 
[/s p  /sp_shunt  /sr  0.01]  cnew 
[/be  /bc_l  /v  100  /eff  0.85]  cncw 
[/res  /rcs_ti  /r  le-4]  cncw 
[/res  /rcs_bc  /r  lc-4]  cncw 
[/rad  /rad_prim  /t  1000]  cncw 
[/rad  /rad_shunt  /t  400]  cncw 
[/rad  /rad_bc  A  400]  cncw 
[/bus  /bus_l]  cnew 
[/mass  /mass_sys]  cncw 
[/task  /a]  cncw 


(a.c) 

(/rcacj.pow  80c4  40c4  120c4  vary 

rcac_l.c  ti_l.c  sp_shunt.c  rcsji.c  bc_l.c  res_bc.c  bus_l.c 

rcac_l.s  rad_prim.c 

sp_shunt.s  rad_shunLc 

bc_l.s  rad_bc.c 

Acac_l.pow  (bus  l.fl.pow-40c3)  cons 

) 

while 

mass_sys.c  flows.print  mods.print 
/all  cdel 

The  output  for  this  GTS  input  is  shown  in  Appendix  F.  Note,  that  this  output  should  not  be  considered  a  typical 
thermionic  system  as  not  all  of  the  parameters  had  reasonable  values  assigned  to  them.  This  example  is  only 
meant  to  show  what  a  typical  input  and  its  resulting  output  would  look  like. 


CHAPTER  6 


Graphics 


6.1.  Introduction 

The  graphics  currently  available  within  GPS  arc  only  preliminary  but  are  sufficient  to  generate  simple  two- 
dimensional  plots  and  system  diagrams  of  component  layouts.  The  two-dimensional  plots  arc  implemented 
using  a  model  class,  a  networking  communications  package,  and  the  NeWS  toolkit  wire  server.  The  system 
diagrams  also  make  use  of  the  wire  server  and  thus,  the  graphics  only  arc  available  when  this  wire  server  is 
available. 

6.2.  Two-dimensional  Plots 

Two-dimensional  plots  of  arbitrary  user  selected  independent  (x  values)  and  dependent  (y  values)  variables  are 
generated  by  using  a  model  class  denoted  as  plot.  For  each  plot  desired  an  instance  of  this  plot  class  should  be 
generated  using  cnew.  When  the  plot  class  instance  is  generated  a  new  window  will  pop  open  on  the  screen. 
Initially,  the  window  will  be  blank  with  only  the  label  specified.  The  label  will  be  the  same  as  the  plot  class 
instance  name. 

The  variables  that  can  be  defined  for  the  plot  model  arc  as  follows, 
xl  -  character  string  representing  the  x-axis  label  ("x-axis").  Input, 

xlb  -  lower  bound  of  the  independent  variables  (0.0).  Input, 

xub  -  upper  bound  of  the  independent  variables  (1.0).  Input 

yl  -  character  string  representing  the  y-axis  label  ("y-axis").  Input, 

ylb  -  lower  bound  of  the  dependent  variables  (0.0).  Input 

yub  -  upper  bound  of  the  dependent  variables  (1.0).  Input 

At  present,  the  increment  used  along  each  axis  is  one  fifth  of  the  total  axis  length. 

The  data  for  each  plot  is  obtained  by  using  the  c  function  for  the  class.  This  function  requires  arguments 
and,  as  such,  will  need  to  be  called  using  the  call  operator.  The  arguments  arc  nothing  more  than  the  x,y  pairs 
of  data  to  be  plotted.  Thus,  one  would  write 

[x  y]  /plotl.c  call 

to  plot  the  x,y  pair  in  plotl.  The  plots  generated  use  straight  line  segments  between  the  plotted  points. 

At  present  there  is  no  delay  between  poping  open  a  window  and  continuing  the  execution  of  the  GPS 
input.  Thus,  since  the  act  of  poping  open  a  window  may  take  some  time,  it  is  possible  for  very  simple  problems 
that  the  entire  GPS  input  may  have  been  executed  before  the  plot  window  has  been  opened.  No  data  is  lost  in 
this  case,  as  the  data  going  to  the  plot  window  is  stored  and  simply  plotted  when  the  window  becomes  opened. 
At  present,  only  400  x,y  pairs  are  stored  per  window.  A  check  is  made  when  doing  the  plotting  that  the  new  x,y 
pair  is  at  least  one  pixel  different  than  the  previous  x,y  pair.  Thus,  400  values  are  usually  sufficient  for  most 
plots.  Data  is  also  properly  stored  if  a  plot  window  is  closed. 

As  the  plot  windows  are  based  on  the  OpcnLook  windows,  these  plot  windows  can  be  moved,  resized, 
closed,  and  open.  The  resizing,  however,  does  not  resize  the  plot  itself.  Any  damage  to  the  window  is  automat¬ 
ically  repaired  from  the  data  stored  for  the  plot.  As  the  window  is  receiving  information  from  both  the  GPS 
code  via  the  communications  package  and  through  the  mouse  interactions,  the  plot  windows  are  implemented  as 
separate  processes.  Thus,  one  can  quit  a  GPS  session  and  any  plot  windows  generated  will  remain.  These  win¬ 
dows  can  be  terminated  by  using  the  quit  item  of  the  windows  frame  menu. 
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The  following  GPS  input  is  an  example  of  the  use  of  the  plot  class  . 
cinit 

[/plot  /a  /x l  "x  label"  /xub  2.0]  cnew 
[/plot  /b  /xl  "x  stuff”  /xub  2.0  /yl  "z  stuff]  cnew 
[/plot  /c  /xub  2.0  /yl  "uavg”]  cnew 
0  0.1  2.0 

{/x  exch  def  /y  (0.25*x*x)  def  /z  (exp(-x))  def 
[x  y]  /a.c  call 
[x  z]  /b.c  call 
[x  (x*exp(-x))]  /c.c  call 

} 

for 

/all  cdcl 

Here  three  plot  windows  will  be  popped  open  showing  in  window  "a”  a  plot  of  x2/4  versus  x  from  0  to  2.0,  in 
window  "b"  a  plot  of  e~x  versus  jc,  and  in  window  "c"  a  plot  of  xe~x  versus  x. 

6.3.  System  Diagrams 

As  mentioned  previously,  GPS  can  be  used  to  create  system  diagrams,  such  as  those  used  in  Figures  1,  2  and  3. 
This  is  done  by  using  the  mods.config  function.  For  each  collection  of  components  there  is  a  C  function 
denoted  as  modsconfig,  which  will  read  a  GPS  input  file,  parse  it  into  the  components  that  are  being  used,  and 
then  pop  open  a  window  in  which  a  very  simple  linear  representation  of  the  system  appears.  This  simple  system 
diagram  can  then  be  edited  into  a  reasonable  representation  of  the  system  under  consideration. 

The  next  section  discusses  the  GPS  inputs  necessary  to  pop  open  this  configurations  window  followed  by  a 
section  that  discusses  the  editing  of  the  diagram  using  the  mouse.  This  feature  of  generating  the  system 
diagrams  requires  the  use  of  the  SUN  NcWS  window  environment. 

6.3.1.  Configuration  Windows 

The  mods  stack  class  generally  has  a  config  function  which  when  called  will  generate  a  configuration  file  and 
then  pop  open  a  NeWS  window  in  which  the  system  configuration  diagram  can  be  edited.  This  function  requires 
one  character  string  argument  representing  the  name  of  the  GPS  input  file.  Thus,  in  order  to  generate  the 
configuration  window,  one  must  first  initialize  the  mods  stack  class  using  a  call  to  cinit  and  then  use  the  call 
operator  to  call  the  mods.config  function  with  the  file  argument.  Thus,  the  GPS  input  necessary  would  look  as 
follows. 

cinit  ["filc.daf  ]  /mods.config  call 

Here  "file.dat"  is  the  name  of  the  GPS  input  file  representing  the  system  for  which  a  diagram  is  required.  Note 
that  this  input  file  is  noting  special,  just  the  typical  input  that  was  specified  in  the  examples  previously  given. 
System  constraints,  parameter  sweeps,  optimizations,  etc,  arc  all  ignored  by  the  mods.config  function  as  they  arc 
not  pertinent  to  the  generation  of  the  system  diagram. 

Once  mods.config  has  been  called  the  mouse  cursor  will  change  to  a  ’+’  indicating  to  the  user  to  size  a 
window  (using  the  middle  mouse  button).  Initially,  the  window  will  display  the  system  diagram  as  a  scries  of 
linear  flow  paths,  some  of  which  may  be  longer  than  that  of  the  window.  The  editing  of  the  flow  paths  into  a 
reasonable  looking  diagram  is  done  entirely  with  the  mouse  and  the  left  and  middle  mouse  buttons.  Once  the 
user  is  satisfied  with  the  diagram  the  right  mouse  button  can  be  used  to  pop  open  the  main  menu. 

Only  four  menu  items  exist.  The  first  is  to  save  the  diagram.  If  selected  the  diagram  is  saved  into  a  file 
denoted  as  "file.conf,  where  "file"  is  the  same  name  as  used  originally  in  the  GPS  mods.config  call.  The 
second  item  is  for  repainting  the  diagram  in  case  of  damage  that  has  not  automatically  been  repaired.  The  third 
item  is  to  print  the  diagram  on  the  primer.  This  item  also  generates  the  file  named  "gsalt.prt".  This  file  is  the 
PostScript  code  that  was  used  to  generate  the  diagram  on  the  printer  and  can  be  resaved  and  edited  manually  if 
desired.  Note  that  "gsalt.prt"  is  overridden  each  time  a  new  diagram  is  printed.  Finally,  the  last  menu  item  is 
for  quitting  the  diagram  window. 

The  call  to  mods.config  returns  almost  immediately,  since  it  really  generates  a  new  UNIX’s  process  for 
dealing  with  the  system  diagram  editing.  Thus,  it  is  possible  to  actually  place  the  call  to  mods.config  in  the 
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same  file  that  is  being  called,  although,  it  is  probably  more  useful  to  manually  type  the  mods.config  call  and 
generate  a  diagram  before  actually  running  the  system  problem  using  GPS.  This  is  because  the  diagram  clearly 
shows,  even  though  it  is  not  well  laid  out,  the  model  connectivity  that  the  GPS  inputs  have  defined.  Thus,  the 
diagram  might  show  an  error  that  has  been  made  in  defining  the  configuration  with  the  model  calls. 

Once  a  diagram  has  been  generated  and  saved  for  a  given  inptu  file,  this  diagram  is  used  the  next  time 
mods.config  is  called.  This  is  true  even  if  the  new  GPS  file  has  been  edited  to  a  slightly  different  configuration 
possibly  with  a  greater  or  lesser  number  of  models.  The  mods.config  will  attempt  to  merge  the  new 
configuration  with  the  old  so  that  less  diagram  editing  will  be  required  to  generate  a  reasonable  looking  diagram 
the  next  time.  It  should  be  noted,  however,  that  the  diagram  requires  layout  information  that  is  not  provided 
when  using  GPS  to  analyze  a  system  and  thus,  when  new  models  are  added  to  a  configuration  some  strange 
looking  diagrams  may  initially  appear.  However,  during  the  diagram  editing  no  models  can  be  added  or 
removed  and  the  connectivity  of  the  flows  between  the  models  can  not  be  altered  in  any  way,  only  the  layout 
can  be  altered.  In  other  words,  the  diagram  can  only  represent  what  was  set  up  within  the  GPS  inputs. 

6.3.2.  Diagram  Editing 

As  mentioned  previously,  all  the  editing  of  a  diagram  is  done  using  the  mouse.  Basically,  there  are  only  two 
main  ideas  in  editing  a  diagram.  The  first  is  moving  the  component  models  around  and  the  second  is  anchoring 
one  or  more  of  the  models  so  that  they  will  not  be  moved  as  others  are.  The  moving  of  components  is  accom¬ 
plished  using  the  middle  mouse  button  and  the  anchoring  is  done  using  the  left  mouse  button.  In  each  case,  the 
models  of  a  flow  path  arc  affected.  By  "flow  path",  we  mean  a  collection  of  models  that  are  passed  through  by 
a  single  flow.  The  first  model  in  the  path  will  generate  the  flow  and  the  last  will  generally,  terminate  the  flow. 
Thus,  for  example,  in  the  dynamic  models,  the  gas.c,  sp.s,  and  shftc  model  calls  generate  flows  and  the  mx.s, 
exnz.c,  and  shft.cnd  model  calls  will  terminate  flows. 

Assuming  first,  that  no  anchored  models  have  been  specified,  by  placing  the  mouse  cursor  on  a  model, 
pressing  and  holding  the  middle  mouse  button,  and  then  dragging  the  mouse  to  a  new  point,  the  pointed  to 
model  is  translated  rcctilinearly  to  the  new  location.  All  other  models  within  the  flow  path  that  this  model  was 
in  arc  also  translated  by  exactly  the  same  vector  translation.  No  rotations  or  distortions  occur. 

By  placing  the  mouse  cursor  on  a  model  and  clicking  (press  and  release)  the  left  mouse  button,  the 
pointed  to  model  is  anchored.  This  is  indicated  by  a  small  V  sign  appearing  within  the  model’s  box.  The 
anchor  can  be  changed  by  repeating  the  procedure  on  another  model.  If  the  left  mouse  button  is  clicked  on  the 
background  no  model  will  be  anchored.  This  anchor  will  be  called  the  primary  anchor.  At  any  one  time  only 
one  model  can  have  a  primary  anchor.  Once  a  model  is  anchored  in  a  flow  path,  the  translation  that  is  done 
using  the  middle  mouse  button  is  altered  in  the  following  way.  Those  models  that  appear  between  the  primary 
anchored  model  and  the  translated  model  undergo  a  rotation,  those  models  that  are  after  the  translated  model 
undergo  the  usual  rectilinear  translation.  By  "after"  we  mean  those  models  that  are  nearest  the  translated  model 
but  not  between  the  translated  and  primary  anchored  models.  Thus,  "after"  could  also  mean  "before"  the 
translated  model  in  the  since  of  the  passage  of  the  flow  through  the  models. 

At  times  it  is  necessary  to  anchor  two  models  within  a  flow  path,  this  is  accomplished  by  pointing  to  the 
first  model,  pressing  the  left  mouse  button,  dragging  the  mouse  to  the  second  model,  and  then  releasing  the  left 
mouse  button.  Both  the  models  should  then  have  the  anchor  signs.  The  model  pointed  to  first,  as  before,  will 
be  the  primary  anchor  and  the  second  one  will  be  called  the  secondary  anchor.  In  this  ease,  the  translations  are 
affected  as  follows.  Those  models  between  the  primary  anchor  and  the  translated  model  undergo  a  rotation, 
while  those  between  the  translated  model  and  the  secondary  anchor  undergo  a  translation.  If  the  translated 
model  is  not  between  the  anchored  models,  the  models  between  the  translated  model  and  the  closest  anchor  (as 
measured  along  the  flow  path)  undergo  the  rotation  and  the  models  "after”  the  translated  model  undergo  a  trans¬ 
lation. 

When  two  models  are  placed  on  top  of  each  other  they  will  fuse  into  a  single  box,  and  a  small  "o"  will 
appear  within  the  box  indicating  that  there  are  overlayed  models  at  this  point  Overlayed  models  also  act  as  if 
they  were  anchored  models.  Small  movements  of  such  overlayed  models  can  only  be  done  by  moving  one 
model  completely  away  from  the  other,  making  the  small  adjustment,  and  then  moving  the  overlayed  model 
back  onto  the  adjusted  model.  Note  that  even  after  a  model  has  had  other  overlayed  models  moved  away  from 
it,  and  thus  effectively  removing  its  overlayed  status,  the  overlay  status  is  not  changed  until  that  model  itself  is 
moved. 
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The  primary  anchor  is  also  used  to  clean  up  vertical  and  horizontal  flow  path  lines.  This  is  done  by 
anchoring  a  model  and  then  clicking  the  middle  mouse  button  on  some  other  model  approximately  vertical  or 
horizontal  to  the  anchored  model.  When  this  is  done,  the  adjusted  model  will  jump  to  exactly  vertical  or  hor¬ 
izontal  position  relative  to  the  anchored  model.  In  this  ease  the  adjusted  model  docs  not  have  to  be  within  the 
same  flow  path.  Thus,  models  in  different  flow  paths  can  be  aliped  relative  to  each  other. 

Initially,  the  flow  paths  between  the  models  are  straight  line  paths.  This  at  times,  is  not  sufficient,  since 
flow  paths  may  need  to  make  turns,  etc.  A  turn  or  kink  in  the  flow  path,  is  generated  by  simply  pointing  to  a 
model,  pressing  the  left  mouse  button  and  dragging  the  mouse  to  the  very  next  model  in  the  flow  path.  When 
this  is  done,  the  flow  path  will  show  a  small  circle  midway  between  the  two  models.  This  small  circle  can  be 
anchored  and  moved  just  like  any  other  model  in  the  system.  For  ease  of  use,  however,  the  movement  of  the 
circle  only  affects  that  circle.  That  is,  movement  of  the  circle  is  as  if  both  models  on  either  side  of  the  circle 
were  anchored.  Additional  kinks  can  be  generated  by  pointing  to  the  model  or  circle  with  the  left  mouse  button 
and  again  dragging  the  mouse  to  the  next  model  or  circle  in  the  flow  path  and  releasing  the  button.  'Ihe  kinks 
can  be  removed  by  pointing  to  the  kink  with  the  left  mouse  button  and  dragging  the  mouse  to  the  previous  flow 
model  in  the  path  (which  may,  of  course,  be  another  kink)  and  then  releasing  the  mouse  buuon. 


CHAPTER  7 


GPS  Model  Interfacing 


7.1.  Introduction 

In  general  GPS  was  designed  to  be  able  to  reference  both  model  class  functions  and  model  class  data  structure 
elements  by  name.  In  addition,  GPS  was  designed  to  be  as  generic  as  possible  and  not  refer  internally  to  any 
specific  class  type.  In  this  way  GPS  could  simply  be  linked  with  any  suitable  class  library  without  the  need  to 
make  any  changes  to  GPS  itself. 

In  order  to  accomplish  these  goals,  each  model  class  instance  needs  a  way  of  returning  the  location  of  a 
class  member  given  a  literal  reference  for  that  member.  To  do  this,  each  class  has  a  substructure  denoted  as 
refee  which  contains  three  pointers,  one  to  the  class  instance  data  structure  itself,  one  to  the  name  of  the 
instance,  and  one  to  a  reference  function  for  the  class.  This  refee  substructure  is  then  placed  on  a  stack,  denoted 
as  cstack.  GPS  then  references  this  cstack  to  locate  any  particular  model  instance,  which  in  turn,  given  the  loca¬ 
tion  of  the  reference  function  for  the  class.  This  reference  function  can  then  be  called  to  either  locate  a  particu¬ 
lar  model  instance’s  variable  or  call  a  particular  model  function.  More  details  on  the  model  reference  function 
will  be  presented  below. 

New  models  arc  easily  added  to  the  any  of  the  component  libraries  since  each  model  is  essentially  self 
contained.  The  only  interfacing  with  the  GPS  coding  is  through  the  new  model  class  instance  allocator  and  the 
model’s  ref  function.  However,  in  order  to  retrieve  flows  and  make  use  of  the  property  codes  the  model  will 
need  to  make  appropriate  calls  to  the  flow  and  property  class  member  functions.  Once  a  new  model  is 
developed,  it  is  simply  compiled  and  added  to  the  appropriate  component  library. 

In  general,  a  model  may  contain  most  any  C  language  coding  that  is  necessary  to  describe  the  model’s 
phenomena.  However,  because  models  are  called  with  some  of  their  input  parameters  perturbed  slightly  for 
evaluadon  of  dcrivadves  used  in  the  mathematical  utilities,  the  models  must  represent  true  functions  of  the 
inputs.  Thus,  the  same  outputs  should  be  obtained  from  the  model  for  each  call  using  the  exact  same  input 
flows  and  parameter  values.  Note  that  this  precludes  using  some  modeling  parameter  that  uses  a  value  from  a 
previous  call  to  the  model,  unless  that  parameter  is  simply  used  as  an  initial  guess  to  some  iteration.  In  that 
case  these  internal  model  iterations  should  converge  to  a  tolerance  that  still  permits  evaluating  model  parameter 
derivatives  by  finite  differencing.  Internal  iteration  convergence  should  be  kept  fairly  tight  It  does  not  help  to 
speed  up  the  code  by  loosening  the  convergence  criteria,  since  this  will  often  result  in  more  iterations  being  used 
by  flic  driver  coding  in  solving  system  constraints. 

7.2.  Interfacing  example 

In  order  to  describe  the  details  of  adding  a  new  model,  we  will  go  through  the  steps  of  adding  a  fictitious  model 
to  the  dynamic  model  library.  Let  us  suppose  this  model  is  called  xmod  and  requires  one  gastype  flow  and  one 
shfttypc  flow  as  inputs,  both  of  which  are  also  output  flows.  Further,  let  us  suppose  the  model  has  two  parame¬ 
ters,  parml  and  parm2,  both  double  precision  variables  and  that  the  parm2  parameter  is  governed  by  the  equa¬ 
tion 

^  =f  ( parm  \jiarm2,...) 

where  the  function  /  will  be  left  unspecified,  but,  of  course,  would  be  known  for  some  actual  model.  The  steps 
in  developing  this  model  would  amount  to  defining  a  model  class  and  its  member  functions.  The  model  class 
for  this  new  model  would  be  as  follows. 

struct  xmod 
{char  name[16]; 
struct  refee  *z; 
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double  parml,  parm2; 
struct  gastype  fl; 
struct  shfuype  shftf; 

); 

struct  refee  *xmodncwO; 
vo|d  *xmodrefO 

The  first  variable,  name  should  always  be  included.  It  is  used  to  store  the  name  of  the  model  for  use  in  prin¬ 
touts.  Next,  the  structure  refee  is  used  to  locate  this  particular  model’s  variables  and  member  functions  by  the 
GPS  code.  Its  use  and  structure  will  be  described  later.  Following  the  refee  structure  the  two  double  parameters 
arc  declared  followed  by  the  declarations  of  the  gastype  and  shfuype  flows,  where  we  have  used  for  their  names 
fl  and  shftf,  respectively.  These  names  are,  of  course,  anything  the  modeler  wishes  to  use. 

The  model’s  class  member  functions  can  be  anything  the  model  developer  requires.  However,  two  func¬ 
tions  must  be  provided.  The  first  is  an  allocator  function,  recognized  by  having  the  same  name  as  the  model 
class  with  the  suffix  new,  which  takes  as  an  argument  a  character  string  representing  the  model’s  name.  This 
function  must  return  a  pointer  to  the  structure  refee  which  is  defined  in  the  header  file  util.h. 

The  second  is  the  ref  function  which  will  be  used  by  the  GPS  code  to  reference  the  models  variables  and 
functions. 

Once  this  xmod  class  declaration  is  defined,  one  needs  to  code  up  the  member  functions. 

The  new  function  is  called  whenever  an  instance  of  the  class  is  required  and  is  also  the  place  where 
default  values  for  the  model  parameters  can  be  defined.  For  our  xmod  model  we  would  have  the  following. 

xmodnew(char  *s) 

{struct  xmod  *z; 

z=(struct  xmod*)calIoc(l,sizcof(struct  xmod)); 

strcpy(7.->name,s);  z->z.spt=(void*)z;  z->z.namp=z->name;  z->z.rcf=ncwref; 
parml=10,;  parm2=20; 

stackput(mods,(void*)&z->z,(void*)z->name); 

rctum(&z->z); 

) 

Here  an  instance  of  the  xmod  structure  is  allocated  and  the  elements  of  the  refee  substructure  and  the  variable 
name  are  assigned  values.  The  refee  structure  contains  the  three  variables  listed,  spt,  which  points  to  the  newly 
allocated  xmod  structure,  namp  which  points  to  the  model’s  name  and  finally,  ref,  which  is  a  pointer  to  die 
model’s  ref  function.  The  next  iine  gives  the  defaults  to  the  two  model  parameters.  The  coding  here  would  be 
different  for  each  model  and  can  be  most  any  type  of  initializations  the  modeler  needs  to  make.  Finally,  the 
model’s  allocated  structure  is  placed  on  the  mods  stack  by  placing  the  address  of  the  substructure  refee  on  the 
stack  using  the  stackput  function.  The  function  terminates  by  returning  the  address  of  this  refee  substructure. 
Note  that  this  coding  with  the  exception  of  different  ref  functions  and  model  parameters  would  be  the  same  for 
every  new  model. 

The  calculational  function  for  this  xmod  class  is  as  follows. 

void  xmodc(z) 
struct  xmod  *z; 

{double  f; 

z->fl=*gasget();  z->fl.namp=z->namc; 
z->shftf=*shftgctO;  z->shflf.namp=z->namc; 
if  (dyn->statc=0) 

{ 

/*  do  any  initialization  calculations  */ 

) 

f*  evaluate  function  f  */ 
diff(  &z->parm2,  f,  &dyn  ); 
f*  evaluate  exit  flows  */ 
z->fl  = ... 
z->shftf=  ... 
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stackput(gass,(void*)&z->fl,0); 

siackput(shfts,(void*)&z->shftf,0); 

) 

Here  we  declare  a  double  precision  variable  f  to  store  the  value  of  the  time  derivative  of  parm2,  then  we  obtain 
the  gaslype  and  shfttype  flows.  Gasget  simply  retrieves  a  gastype  flo>.  from  the  gass  and  shftget  retrieves  a 
shfttypc  flow  shfts.  After  obtaining  these  flows  their  namp  variable  is  assigned  the  model’s  name.  In  litis  way 
the  model  name  is  associated  with  the  flow  for  printout  purposes. 

If  calculations  are  required  before  the  integrations  over  time  begins  they  can  be  placed  within  a  condi¬ 
tional  block  testing  the  dyn->statc  variable  for  zero.  This  variable  is  only  zero  before  the  integrations  start 

The  modeling  calculations  arc  then  coded.  At  some  place  within  this  modeling  a  call  to  diff  will  be 
required  to  represent  the  xmod’s  differential  equation  and  the  exit  values  for  both  the  11  and  shftf  flows  will 
need  to  be  calculated.  These  arc  then  put  back  onto  their  respective  flow  stacks  using  the  stackput  function. 

The  model  probably  should  have  a  print  function,  which  could  be  coded  as  follows, 

void  xmodprint(z) 
struct  xmod  *z; 

{printf('\i%-12s  parml=%c  parm2=%e"^->name^->parml,z->parm2); 

} 

The  model’s  reference  function  is  denoted  by  the  suffix  ref.  The  ref  function  takes  three  arguments.  The 
first  is  a  pointer  to  the  model  class’s  structure,  the  second  is  a  character  string  argument  representing  a  member 
variable  name,  and  the  third  is  a  char  argument  representing  a  variable  type.  For  variables  that  arc  double  preci¬ 
sion,  integer,  or  character  strings,  type  is  returned  as  either  a ’d’,  ’i’,  or  ’s’.  For  member  functions  type  is 
returned  as  T.  These  are  the  values  displayed  in  Table  3.  In  the  each  of  these  eases,  ref  also  returns  a  pointer 
typed  cast  to  (void*)  representing  the  address  of  the  variable  or,  in  the  ease  of  a  function  returning  no  values,  a 
null  pointer.  Additionally  for  functions,  the  ref  function  will  also  call  the  function  if  type  is  specified  on  input 
to  be  Y.  If  the  function  has  a  returned  value,  type  is  then  reassigned  as  either  a ’d’,  ’i\  or  ’s’.  For  this  xmod 
model  the  ref  function  would  look  like  the  following. 

void  *xmodrcf(z,  st,  type) 
struct  xmod  *z;  char  *st,  *typc; 

{if  (strcmp(st,"c")==0) 

{if  (*type==Y)  xmodc(z);  *typc=’F;  return  0;) 
else  if  (strcmp(st,"print")==0) 

{if  (*type==Y)  xmodprint(z);  *type=’F;  return  0;) 

*typc=’d’; 

if  (strcmp(st,"parml")==0)  return  (void*)&z->parml; 
else  if  (strcmp(st,"parm2")=0)  return  (void*)&z->parm2; 
else 

{printf('V7os,%s  unknownO,z->namc,st);  cxit(-l);} 

} 

Here  xmodref  will  cither  call  the  calculational  function  or  print  function  or  return  the  locations  of  parml  or 
parm2. 

7.3.  Other  requirements 

Besides  these  requirements  on  the  individual  C  model  classes,  the  GPS  code  expects  that  two  functions  will  be 
provided  as  externals.  These  two  functions  are  called  cncw  and  cinit.  Function  cnew  takes  two  arguments.  The 
first  is  a  character  string  pointer  specifying  the  name  of  a  C  model  class  type  and  the  second  is  a  character 
siring  pointer  specifying  the  instance  name  of  that  class  type.  The  function  cncw  should  call  the  new  function 
of  the  appropriate  class  type  returning  the  same  pointer  returned  by  that  model’s  new  function.  It  should  also  put 
that  new  model’s  refee  substructure  on  the  cstack.  Note  that  cnew  is  the  C  function  that  is  used  by  the  GPS 
cnew  operator  to  allocate  C  model  classes.  Thus,  any  class  that  the  GPS  is  to  communicate  with  must  be  recog¬ 
nized  by  the  cncw  function. 
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The  cinit  function  takes  no  arguments  and  returns  a  void.  This  function  is  called  by  the  GPS  cinit  opera¬ 
tor  and  should  allocate,  by  calls  to  cncw,  any  G  model  classes  that  must  exist  for  the  current  collection  of 
classes  that  are  being  linked  to  GPS.  An  example  of  such  a  class  is  the  mods  stack  class  instance  for  storing  the 
model  instances.  Cinit  may  also  perform  any  other  initialization  tasks  needed  by  this  collection  of  classes. 
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APPENDIX  A 


Task  Class  examples 


This  appendix  shows  each  of  the  example  problems  described  in  section  four  and  their  corresponding  output. 
Lines  in  italics  arc  not  part  of  the  inputs  or  outputs  but  were  added  to  label  and  explain  things. 


EXAMPLE  ONE 


cini  t 

[/task  /a]  cncw 
(a.c) 

{/x  1.0  0.0  2.0  vary 
/x  (x*x-cxp(-x))  cons 

) 

while 
/a  cdcl 

task:  a  n=0  f=6.321206c-01 
x=  l.OOOOOOc-fOO 
c=  6.321206e-01 

h=  7. 1266c -02  hs=  7.1266c-02  mu=0.00e+00  n=7.13c-02  s=7.13c-02  a=1.00e400 

a  n=l  f=5. 690847c -02 
a*-  7. 330436c -01 
c=  5. 690847c -02 

h=  5.7761c-04  hs=  5.7761c-04  mu=0.00c-+00  n=6.98e-04  s=6.98e-04  a=1.00c400 

task:  a  n=2  f =6. 026605c -03 
x=  7. 066324c -01 
c=  6. 026605c -03 

h=  6. 4778c -06  hs=  6.4778c-06  mu=0.00e+00  n=9.79c-06  s=9.79c-06  a=1.00c400 

task:  a  n=3  f =6. 978994c -05 
x=  7.035041c-01 
c=  6.978994c-05 
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EXAMPLE  TWO 

cini  t 

[/task  /a]  cncw 
(a.c) 

{/x  2  (-20)  20  vary 
/ y  2  (-20)  20  vary 
/z  2  (-20)  20  vary 
/x  (pow(x-l,2)-y)  cons 
/y  (y-2*log(exp(x)+l))  cons 
/z  (z*z-x)  cons 

) 

while 

"\nx=%.2f  y=%.2f  z=%.2f"  [x  y  z]  printf 
/all  cdcl 

task:  a  n=0  f=2.241267c+00 
x=  2.000000C400  2.000000e +00  2.000000c+00 
c=-1.000000c+00  1.525738e -01  2.000000e+00 

h=  5. 2328c -01  hs=  5.2328c-01  mu=4.55e-01  n=7.17e-01  s=1.68c-01  a=6.30c-01 

task:  a  n=l  f=4.511650e-01 
x=  2.603536c+00  2.215696e+00  1.690980c+00 
c=  3. 556303c -01  -1 .077238c-01  2.558760c-01 

h=  4. 73 15c -02  hs=  4.7315e-02  nu=0.00e-t00  n=3.66c-02  s^l.37c-02  a=7.23e-01 

task:  a  n=2  f=1.463562c-01 
x=  2.442031e+00  2.197887c+00  1.589939e+00 
c=-l . 184341e-01  4.319375c-03  8.587682e-02 

h=  3. 9862c -03  hs=  3.9862e-03  mu=0.00e+00  n=3.81e-03  s=8.62e-04  a=6.27e-01 

task:  a  n=3  f=l. 840560c -02 
x=  2.491854c+00  2.233754c+00  1.583782c+00 
c=-8. 126091c-03  2.959046c-04  1.651197e-02 

h=  3. 3636c -05  hs=  3.3636c-05  mj=0.00c+00  n=3.47c-05  s=7.34c-06  a=6.93c-01 

task:  a  n=4  f=l .664113c-03 
x=  2.495687C+00  2.236516c+00  1.580270c+00 
c=  5.629013C-04  -1.760654c-05  1.565920c-03 

h=  2. 3278c -07  hs=  2.3278c-07  mu=0.00c+00  n=3.21c-07  s=6.46e-08  a=8.22c-01 

task:  a  n=5  f=2.549055e-04 
x=  2.495456C+00  2.236347c+00  1.579781e+00 
c=  4.208626e-05  -1 .330936c-06  2.514037e-04 

x=2.50  y=2.24  z=1.58 


78 


EXAMPLE  THREE 


cinit 

[/task  /a  ] 

cncw 

[/task  /b  ] 

cncw 

/z  2.0  dcf 

(a.c) 

{/x  2.0 

(-20) 

/y  2.0 

(-20) 

(b.c) 

{/ z  z  (-20)  20  vary 
/z  (z*z-x)  cons 

) 

while 

/x  (pow(x-l  ,2)-y)  cons 
/y  (y-2*log(exp(x)+l))  cons 

) 


whi  le 

"\nx=%.2f  y=%.2f  z=%.2f"  (x  y  z]  printf 
/all  cdel 


task:  b  n=0  f=2.000000e+00 
x=  2. 000000c +00 
c=  2.000000c+00 

h=  2.5000c-01  hs=  2.5000e-0!  tiu=0.00c+00  n=2.50e-01  s=2.50e-01  a=1.00c+00 


task:  b  n=l  f=2.500001c-01 
x=  1.500000c+00 
c=  2.500001c-01 

h=  3.9063e-03  hs=  3.9063c-03  mi=0.00e+00  n=5.10c-03  s=5.10c-03  a=1.00c+00 

task:  b  n=2  f=4. 08 1634c -02 
x=  1 . 42857 lc+OO 
c=  4.081634c-02 

h=  1.0412e-04  hs=  1.0412c-04  mi=0.00c+00  n=1.94e-04  s=1.94c-04  a=1.00e+00 

task:  b  n=3  f =1.1 89769c -03 
x=  1.414634c+00 
c=  1.1 89769c -03 

h=  8. 8472c -08  hs=  8.8472c-08  mu=0.00c+00  n=1.75c-07  s=1.75c-07  a=1.00c+00 

task:  b  n=4  f=6. 0073 10c -06 
x=  1.414216C+00 
c=  6.007310C-06 

task:  a  n=0  f=1.011572c+00 
x=  2. 000000c +00  2.000000c+00 
c=-l .OOOOOOc+OO  1 .525738c -01 

task:  b  n=0  f =5. 8073 10c -06 
x=  1 .414216c+00 
c=  5.807310c-06 

task:  b  n=0  f =6. 0073 10c -06 
x=  1 .414216e+00 
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c=  6.007310e-06 

h=  2. 7328c -01  hs=  2.7328e-01  mu=1.16e400  n=6.10c-01  s=7.76c-02  a=4.75e-01 

task:  b  n=0  f=4.287017e-01 
x=  1.414216C400 
c=-4.287017c-01 

h=  2. 2973c -02  hs=  2.2973c-02  nu=O.OOc-tOO  n=2.30c-02  s=2.30e-02  a=1.00c+00 

task:  b  n=l  f =2. 297305c -02 
x=  1.565784C+00 
c=  2. 297305c -02 

h=  6. 5970c -05  hs=  6.5970c-05  im=0.00e-t00  n=5.94c-05  s=5.94e-05  a=1.00c400 

task:  b  n=2  f=l . 109025e-03 
x=  1.558075e+00 
c=-l . 109025c-03 

h=  1 .5374c -07  hs=  1 .5374c -07  nu=0.00c400  n=1.26c-07  s=1.26c-07  a=1.00e-t00 

task:  b  n=3  f=2.610819c-06 
x=  1 .558430e+00 
c=-2.610819c-06 

task:  a  n=l  f=l. 058663c -01 
x=  2.428708c+O0  2.l37929c-+00 
c=-4.672299c-02  -9.499813c-02 

h=  9. 5704c -03  hs=  9.5704e-03  n«=1.57c-01  n=3.10c-02  s=1.44c-03  a=5.67c-01 

task:  b  n=0  f=6. 839740c -02 
x=  1.558430C+00 
c=- 6. 839740c -02 

h=  4.8155c-04  hs=  4.8155c-04  mu=0.00c-t00  n=4.82c-04  s=4.82c-04  a=l .00c+00 

task:  b  n=l  f =4. 8 15499c -04 
x=  1.580375c-t00 
c=  4.815499e-04 

task:  a  n=2  f =8. 482725c -03 
x=  2.497102c-t00  2.233778c-t00 
c=  7. 537533c -03  -3 . 89 1300c-03 

h=  2. 9346c -05  hs=  2.9346e-05  ™=0.00c400  n=9.87c-06  s=9.77c-06  a=9.96c-01 

task:  b  n=0  f=2.887597c-03 
x=  1.580375c+00 
c=  2. 887597c -03 

h=  8. 3463c -07  hs=  8.3463c-07  mu=0.00e+00  n=8.35c-07  s=8.35c-07  a=1.00e+00 

task:  b  n=l  f=8.34771 lc-07 
x=  1. 57946 lc+00 
c=  8. 34771 lc-07 

task:  a  n=3  f=1.682825e-03 
x=  2.494696c-t00  2.235799e-+00 
c=-1.681745c-03  6.029810e-05 

h=  7.1070c-07  hs=  7.1070c-07  mu=0.00c-t00  n=1.01c-06  s=1.39c-07  a=5.17c-01 


task:  b  n=0  f=8.133102e-04 
x=  1.579461C+00 
c=-8. 133102e-04 
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task:  a  n=4  f=l .656567e-04 
x=  2.49551 le+OO  2.236386e+00 
c=  1.655548c-04  -5.809680c-06 

x=2.50  y=2.24  z=1.58 
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EXAMPLE  FOUR 


cini  t 

[/task  /a]  cncw 
(a.c) 

{/x  1  0  10  vary 
/y  2  0  10  vary 
/ z  3  0  10  vary 
/x  (x-y)  cons 
/y  (x-z)  icons 

((x-l)*(x-l)+(y-2)*(y-2)+z*cxp(z))  mini 

) 

wtii  lc 

"\nxs%.2f  y=%.2f  z=%.2f"  [x  y  z]  print f 
/all  cdel 

task  a  it=l  meq=l  f=  6.0257e+01 
x=  l.OOOOc+OO  2.0000C+00  3.0000e-+00 
c=-l ,0000c +00  -2.0000c+00 


task  a  i  t=3  nxq=l  f=  2.0499c+01 
x=2.1731c400  2.1731C+00  2.1731e+O0 
c=-5.0266e-06  -1.0053c -05 
1=  6.6432C401 

task  a  it=4  meq=l  f=  1.0251e+01 
x=  1.7231c+00  1.7231C4O0  1.7231e+00 
c=-8.8818e-16  -1.5543c -15 
1=  1.3760C401 


task  a  i t=5  meq=l  f=  4.3308c+00 
x=  1.4263c+00  1.4263C+00  1.1771e+00 
c=-2. 2204c -16  2.4912c-01 
1=  8.9207C+00 

task  a  it=6  mcq=l  f=  1.9493c+00 
x=  1.4975C+O0  1 .4975c+00  7.1147c-01 
c=  O.OOOOc+OO  7.8600C-01 
1=  3.4323c+00 


task  a  il=7  mcq=l  f=  8. 3524c -01 
x=  1.5129c+00  1.5129e+00  2.5859c-01 
c=  O.OOOOc-fOO  1 .2543c+00 
1=  1.6097e+00 

task  a  i t=8  meq=l  f=  5.0001c-01 
x=  1.4973c+00  1.4973e+00  O.OOOOe+OO 
c=  O.OOOOc+OO  1.4973C-KX) 

1=  4. 5265c -01 

task  a  it=9  mcq=l  f=  5.0000c-01 
x=  1.4996c+00  1.4996c+00  O.OOOOc-tOO 
c=  O.OOOOc+OO  1 .4996e+00 
1=  4.4555c-03 
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task  a  it=10  meq=l  f=  5.0000c -01 
x=  1 .5000c +00  1.5000c +00  0.0000e+00 
c=  O.OOOOc+OO  1 .5000c +00 
1=  9.8042e-04 

x=l . 50  y=l . 50  z=0.00 
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EXAMPLE  FIVE 


cinit 

[/task  /a  /prt  0]  cncw 
1.0  1.0  5.0 

(/a. tout  cxch  def 
(a.c) 

{/x  1.0  vary  /y  2.0  vary 
/x  (-x)  diff 
/y  (0.5*y)  diff 
/z  (x-y)  diff 

} 


/z  0.0  vary 


whi  1c 

"\ntimc=%.2f  x=%.3c  y=$>.3c  z=%.3e"  [a. time  x  y  z]  printf 


for 

/all  cdcl 

t irrc=l .00  x=3.680c-01  y=3.298e+00  z=-1.964c+00 
tinu=2.00  x=1.355c-01  y=5.438c400  z=-6.011e+00 
tinc=3.00  x=4.983e-02  y=8.966e+00  z=-1.298e+01 
tinc=4.00  x=1.834e-02  y=1.478c401  z.=-2.458c+01 
t imc=5 . 00  x=6.739c-03  y=2.437c+01  z=-4.375e401 
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EXAMPLE  SIX 


cini  t 

[/task  / a  /prt  0]  cnew 

/intcrup  {"\ntime=$e"  [a. time]  printf  sintrp)  def 
/trap  1.0  def 
/p  1.0  def 
1.0  1.0  10.0 

(/a. tout  exch  def 
(a.c) 

{(a.statc<=2  <&&  a.timc>=trap)  (intcrup)  if 
/x  1.0  vary  /y  2.0  vary  /z  1.0  vary 
/x  (-x*p)  diff 
/y  (0.5*y)  diff 
/z  (x-y)  diff 

) 

wlii  le 

"\ntinc=%.2f  x=3&.3c  y=%.3c  z=3fc.3c"  [a. tine  x  y  z]  printf 

) 

for 

/all  cdcl 

gps>  "ex6.dat"  run 

tirm=1.00  x=3.680c-01  y=3.298c+00  z=-9.642c-01 

timc=1.000000c+00 

gps_int>  x  =  y  =  p  = 

3.6800e-01 
3.2981c+00 
l.OOOOc+OO 
gps_inl>  /p  1.1  def 

gps_int>  /trap  8.2  def  resurc 

time=2.00  x=1.223e-01  y=5.438c+00  z=-5.021e-tO0 
time=3.00  x=4.086e-02  y=8.967c400  z=-1.2O0c+Ol 
tine=4.00  x=1.352e-02  y=1.479c+01  z=-2.363c-t01 
tirm=5.00  x=4.522e-03  y=2.439e-t01  z=-4.282e401 
tinre=6.00  x=1.490c-03  y=4.024e+01  z=-7.452c+01 
tiuc=7.00  x=4.985c-04  y=6,636c+01  z=-1.267e+02 
timc=8.00  x=1.667c-04  y=1.094e+02  z=-2.129c+02 
limc=8.229812c+00 
gps_int>  /trap  11.0  def  resume 

timc=9.00  x=5.493c-05  y=1.805c+02  z=-3.551c-K)2 
tine=10.00  x=1.838c-05  y=2.977c-t02  z=-5.894c+02 
gps>  quit 


APPENDIX  B 


Steady-State  Example  Fom- 


thermodynamic  data  for  IMHDGEN  with  fiov  id  =  U-R-tlE 

pc=12. 800000,  tc=33. 200000,  tb=20. 400000,  molwt=2. 016000 


output  of  model  flews 


model 

tenp 

pres 

mass 

enth  entr 

dens 

vclc 

qual 

tank_h2 

20.0 

1.29 

7.387 

-4. 1363e+06  -1.0676e+O5 

7.716e+01 

200.0 

0.00 

pimpjp 

24.8 

7.96 

7.387 

-4.1232e+06  -1.0623c+05 

6.783c+01 

200.0 

0.00 

pump_hp 

39.0 

139.22 

7.387 

-3 . 881 le+06  -1.0235e+05 

7.148e+01 

200.0 

1.00 

ht_nz 

579.4 

139.22 

7.387 

3.9117c+06  -5.8868e+04 

5.672e+00 

200.0 

1.00 

sp_2 

579.4 

139.22 

5.171 

3.9117e+06  -5.8868e4t)4 

5.672e+00 

200.0 

1.00 

sp_l 

579.4 

139.22 

3.620 

3.9117e406  -5.8868e+04 

5.672e+00 

200.0 

1.00 

gtjp 

562.8 

85.91 

3.620 

3. 6566c +06  -5.7260e+04 

3.658e+00 

200.0 

1,00 

sp_2 

579.4 

139.22 

2.216 

3.9117e+06  -5.8868e+04 

5.672C+00 

200.0 

1.00 

sp_l 

579.4 

139.22 

1.551 

3.9117e+06  -5.8868e+04 

5.672e+00 

200.0 

1.00 

gt-hp 

521.6 

85.74 

1.551 

3.0768e+06  -5.8324e+04 

3.935e+00 

200.0 

1.00 

mix  turb 

550.4 

85.74 

5.171 

3.4827e+06  -5.7565e+04 

3.732e+00 

200.0 

1.00 

mix  rcac 

559.6 

85.74 

7.387 

3.6U4e+06  -5.7333e+04 

3.672c+00 

200.0 

1.00 

reactor 

2930.0 

85.74 

7.387 

4.2500e+07  -3.1131e+04 

7.145e-01 

200.0 

1.00 

ht_nz 

2498.4 

85.74 

7.387 

3.4708c+O7  -3.4007e+04 

8.371c-01 

200.0 

1.00 

nozzle 

757.1 

0.10 

7.387 

6.3970e+06  -2.5123e+04 

3. 245c -03  7527.4 

1.00 

tank_h2  dt=0. 0000c +00  dp=0.0000e+00  drH3.0000c+00  dh=0.0000e+00 

purp_lp  cff=0. 7000c -01  pcwer=-9.6565e+04 

pump_hp  effc8.1000e-01  powr=-l  ,7881c+06 

ht_nz  heat=5.7566c+07  lmtd=2.4046e+03 

sp_2  sr=3. 0000c -01 

sp_l  sr=3.0000c-01 

gtjp  cffi=2. 3000c -01  pcwcr=9.2323e+05 

gtjip  cff=7. 5000c -01  powsr=1.2951c+06 

reactor  hcat=2.8727e+08 

nozzle  cff=8.5000e-01  arca=3.0240e-01  vel=7.5274e+03  mach=3 . 5986e+00 

thrust=5.8669e+04  inpul  se=8. 1042c+02 


output  of  model  powers 


model 

input 

loss 

prod 

cons 

pinpjp 

O.OOOOc+OO 

O.OOOOe+OO 

O.OOOOe+OO 

9.65o5c+04 

pumpjip 

O.OOOOc+OO 

O.OOOOc+OO 

O.OOOOe+OO 

1.7881e+06 

gt_lp 

0.0000e+00 

O.OOOOe+OO 

9.2323C+05 

O.OOOOe+OO 

gt_hp 

O.OOOOe+OO 

O.OOOOc+OO 

1.2951C+06 

O.OOOOe+OO 

reactor 

2.8727e+08 

O.OOOOe+OO 

O.OOOOc+OO 

0  0000e+00 
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APPENDIX  C 


Steady-State  Example  Four  with  Constraints 


thenrodynamic  data  for  HffRDGEN  with  flow  id  =  1HR-tH2 

pc=12. 800000,  tc=33. 200000,  tb=20. 400000,  moiwt=2. 016000 

task:  a  n=0  f=9.624907e+05 
x=  3.000000c-01  3.000000C-01 
c=  8.266618c+05  -4.929691c+05 

h=  4.0590e-01  hs=  4.0590c-01  nu=0.00c+00  n=2.01c-01  s=1.75c-01  a=9.65c-01 

task:  a  n=l  f=6.200406e+05 
x=  6.588144c-01  5.679687c-01 
c=  1.811617e+05  -5.929846c+05 

h=  3. 7735c -02  hs=  3.7735e-02  mu=0.00c-400  n=2.83c-02  s=2.81e-02  a=9.99c-01 

task:  a  n=2  f=2.498952c+05 
x=  6.588144c-01  7.362034e-01 
c=  7.301368c+O4  -2.389908c405 

h=  6.1294c-03  hs=  6.1294c-03  nu=0.00c+00  n=1.29c-02  s=1.25c-02  a=9.97c-01 

task:  a  n=3  f=7.841918e-05 
x=  6.588144c-01  8.497832c-01 
c=-2.291224c-05  7.499731e-05 


output  of  model  flows 


model 

temp 

pres 

mass 

enth  entr 

dens 

velc 

qual 

tank_h2 

20.0 

1,29 

7.387 

-4.1363c+06  -1.0676e+05 

7.716e+01 

200.0 

0.00 

pmp_lp 

24.8 

7.96 

7.387 

-4.1232C+06  -1.0623c+05 

6.783c+01 

200.0 

0.00 

pmp_hp 

39.0 

139.22 

7.387 

-3.8811c+06  -1.0235e+05 

7.148e+01 

200.0 

1.00 

ht_nz 

579.4 

139.22 

7.387 

3.9117e+06  -5.8868e+04 

5.672e+00 

200.0 

1.00 

sp_2 

579.4 

139.22 

2.520 

3.9117c+06  -5.8868e+04 

5.672e+00 

200.0 

1.00 

sp_l 

579.4 

139.22 

0.379 

3.9117e+06  -5.8868e+04 

5.672e+00 

200.0 

1.00 

gt_lp 

562.8 

85.91 

0.379 

3, 6566c +06  -5.7260e-+04 

3.658e+00 

200.0 

1.00 

sp_2 

579.4 

139.22 

4.867 

3.9117c+06  -5.8868c+04 

5.672c+00 

200.0 

1.00 

sp_l 

579.4 

139.22 

2.142 

3.9117c+06  -5.8868e+04 

5.672e+O0 

200.0 

1.00 

gt-hp 

521.6 

85.74 

2.142 

3.0768e+06  -5.8324e+04 

3.935c+00 

200.0 

1.00 

mix  turb 

527.8 

85.74 

2.520 

3. l639e+06  -5.8157c+04 

3.889C+00 

200.0 

1.00 

mix  rcac 

562.8 

85.74 

7.387 

3 . 6566c +06  -5.7252e+04 

3.651c+00 

200.0 

1.00 

reactor 

2930.0 

85.74 

7.387 

4. 2500c +07  -3.1131c+04 

7. 145c -01 

200.0 

1.00 

ht_nz 

2498.4 

85.74 

7.387 

3.4708c+07  -3.4C07e+04 

8.371C-01 

Z\A) .  W 

1.00 

nozzle 

757.1 

0.10 

7.387 

6.3970c+06  -2.5123c+04 

3. 245c -03 

7527.4 

1.00 

tank_h2  dt=0.0000c+00  dp=0.0000c+00  dm=0.0000e+00  dh=0.OOOOe+OO 

pirrp_lp  cff=6. 7000c -01  powcr=-9.6565c+04 

purp_hp  cff=8. 1000c -01  pwcr=-l  .7881C406 

ht_nz  hcat=5.7566c+07  lmtd=2.4046c40? 
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sp_2 

sr=6.5881e-01 

sp_l 

sr=8.4978e-01 

gt.lp 

cff=2.3000e-01  po*cr=9.6565c404 

gt-hp 

eff=7. 5000c -01  po*cr=1.7881c406 

reactor 

hcat=2.8694c+08 

nozzle 

ef£=8. 5000c -01  arca=3.0240e-01  vel=7.5274e+03  rmch=3 . 5986C400 
thrust=5.8669e+04  inpul sc=8. 1042e-t02 

output  of  model  powers 


model 

input 

loss 

prod 

cons 

pump_lp 

0.0000e+00 

O.OOOOe+OO 

0.0000e400 

9.6565C404 

pump_hp 

O.OOOOc-tOO 

0.0000c  400 

0.0000c400 

1.7881C406 

gt.lp 

0.0000c+00 

0.0000e400 

9.6565C404 

0.0000C4O0 

gl-hp 

0.0000e+00 

0.0000c 400 

1.7881C406 

0.0000c400 

reactor 

2.8694e-t08 

0.0000e400 

0.0000e400 

0.0000e400 

APPENDIX  D 


Dynamic  Example  One  at  Design  Point 


thermodynamic  data  for  HflHXEN  with  flow  id  =  THR-tH2 

pc=12. 800000,  tc=33. 200000,  tb=20. 400000,  m>lwt=2. 016000 

task:  sta  n=0  f=7.563290e+04 
x=  5. 276954c -02  5.000000e-02  2.000000e-02 
c=  6.425210e-01  3.602149e401  -7.563289C404 

h=  3.7461e-04  hs=  3.746lc-04  mi=l .Olc-tOO  n=7.54e-M  s=1.02e-04  a=7.46c-01 

task:  sta  n=l  f=1.973103c404 
x=  4.488375e-02  7.153655e-02  3.305220e-02 
c=  1 .428151C-01  1 . 134402c-K)2  -1.973071C404 

h=  3. 7498c -05  hs=  3.7498c-05  rru=8.88e-03  n=8.54c-05  s=5.45c-05  a=9.76e-01 

task:  sta  n=2  f=l . 175786c+03 
x=  4.153330c-02  8.905709e-02  3.750814c-02 
c=-3. 152815c-03  4.201986c+01  -1. 175035e4O3 

h=  1.8831c-06  hs=  1 .8831c-06  mu=0.00c+00  n=3.27e-06  s=5.28c-07  a=6.27e-01 

task:  sta  n=3  f=9.639517c401 
x=  4. 117667c-02  9.321568e-02  3.777773c-02 
c=-1.281143c-03  1.520944e-t01  -9.518771C-+01 

h=  2. 3726c -07  hs=  2.3726c-07  mu=0.00c400  n=6.48c-07  s=6.97c-08  a=5.00c-01 

task:  sta  n=4  f=3.650815c4<X) 
x=  4.102025c-02  9.509075c-02  3.780441e-02 
c=-1.123252c-04  2. 114729c+00  -2.975966C400 

h=  4.5750c-09  hs=  4.5750c-09  mu=0.00e+00  n=1.56c-08  s=1.36c-09  a=4.52c-01 

task:  sta  n=5  f=1.629713c-01 
x=  4. 099520c -02  9.538108c-02  3.780582e-02 
c=-4.213630c-06  7.386692c-02  -1 .452699c-01 

h=  5.5828c-12  hs=  5.5828c-12  mi=0.00c400  n=2.06c-ll  s=1.64c-12  a=4.38e-01 

task:  sta  n=6  f=3.698913c-03 
x=  4. 099430c -02  9.539164c-02  3.780588e-02 
c=-7.882591c-09  -5.6l4356c-06  3.698909c-03 

h=  7.9740c-19  hs=  7.9740c-19  mu=0.00c400  n=5.52c-18  s=1.24c-19  a=5. llc-01 
convergence  of  independent  variables  in  task  sta 


output  of  model  flows 


model 

temp 

pres 

mass  enth  entr 

dens 

velc 

gas_h2 

20.0 

3.00 

1.000  -4.1681e-+06  -1.0917C405 

7.739C401 

6.6 

val v_tsov 

20.0 

2.94 

1.000  -4.1681C406  -1.0915C4O5 

7.745C401 

6.6 

P'-l 

20.0 

2.94 

1.000  -4.1681C406  -1.0915C4O5 

7.745C401 

6.6 

qual 

0. 

0. 

0.00 
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pump  tp  33.4  86.94  1.000  -3.9990C406  -1.0425c+05  7.059e+01  6.6  1 

valv  psov  33.4  85.20  1.000  -3. 9990e406  -1.041 6e405  7.024c-K)l  6.6  1 

pi  2  33.4  85.19  1.000  -3.9990C406  -1.0415e405  7.023C401  7.3  1 

hi_r  80.0  85.02  1.000  -3.1339c+06  -8.5652c-t04  2.814*401  4.5  1 

sp  1  80,0  85.02  0.905  -3.1339e+Q6  -8.S652C404  ,’.814e+01  16.4  1 

pi  3  80.0  85.02  0.905  -3.1339*406  -8. 56510404  2. 8146401  45.5  1 

rcac  1  3000.0  81.54  0.905  4.3783C407  -3.049O?.4()4  6.639e-01  693.9  1 

sp_2  3000.0  81.54  0.870  4.3783C407  -3.04902404  6.639c-01  667.7  1 

cxnz  1  1142.1  1.10  0.870  1.2123C407  -2.8902C404  2. 361e-02  8318.3  1 

sp _ 1  80.0  85.02  0.095  -3.1339*406  -8.5652C404  2.814*401  43.2  1 

valv  tcv  79.6  81.54  0.095  -3.1339*406  -  8. 5496240.  2.728*401  43.2  1 

pi_5  79.6  81.53  0.095  -3.1339C406  -8.5496C404  2.728e401  44.5  1 

sp  2  3000.0  81.54  0.034  4. 3783*407  -3.0490*404  6.639e-0A  26.2  1 

pi_4  3000.0  81.53  0.034  4.3783*407  -3.0489C404  6.638e-Ol  26.2  1 

ok_1  948.5  81.53  0.130  9.2476C406  -4.9486e404  7.073*400  198.5  1 

pi_6  948.5  81.52  0.130  9. 2476C406  -4.9485*404  2  078*400  198.5  1 

valv  sev  950.0  40.76  0.130  9.2476C406  -4.6593C404  1.046e400  198.5  1 

pi„7  950.0  40.76  0.130  9.2476<-,406  -4.6593e404  1.046e400  394.5  1 

g»_tp  862.3  27.17  0.130  7.9430c+06  -4.6350e4O4  7.697e-01  394.5  1 

cxnzjf  725.5  14.71  0.130  5  9485C406  -4.6326e404  4.963c-01  2046.4  1 

output  of  model  parameters 

gas_h2  dian*=5.0C00c-02  arca=l. 9635c -03 

valv_tsov  dp=6. 0000c  02  pf=2.0000c-02 

pi_l  dp=5.8800c-04 

1  eng th=l. 0000*400  diam=5. 0000c -02  arca=1.9635c-03 
rat„pf-2.0000c-04  rat_m=1.0000c+00 
num _^ar=1.00 

punp_tp  rpnt=6. 0000*404  dp=8.4001c401  ef£=6. 5000c -01  power=-1.6907c405 

rat_dp=8. 4000c  401  rat_tctquc=2. 0577*401  rat_rpm=6. 0000c  *04 
ratjn=1.0000c400  rat_cf£=8.5000e-01  inert ia=7.000Qc-01 
valv  psov  dp=l. 7388*400  pf=2.0G00ft-02 

pi. 2  dp=8.5201e-03 

lcngth=1.0000c400  dian=5.0000*-02  a«ea=l.9635e-03 
rat_pf=l  .0000c-04  ru t_nv*l . 0000c400 
nim_par=l .00 

ht_r  hcat=8.6509e+05  do  =l./039e-01 

ua=l  .0000*405  c{wul=1.0000c403  nvvall=0.0000c400  vol=7.853982c-03 
diam=l  .0000c -01  ^*3=7.85406-03  lcngth=i  .0000c 400 
tconst=l. 0000c  401 
sp  .1  sr=9. 5392c -02 

dian<3=5. 0000c -02  diaml=1.0000c-02  arca0=l. 9635c -03  areal=7.8540c-05 
pi J  dp=6. 9575c -03 

lcngth=l.CO0Oe4OO  dvfc,n=3.0000c-02  area=7.0686c-04 
rat_pf=l .0000e-04  ratjn=l,0000c400 
nun_par=1 .00 

rcaCj  pwxjr=4.2442c407  tfud=3.0054e+03  tclad=0. 0000*400  dp=3. 4785*400 

lmtd=4.6438ev02 

mf uc  1  -2 . 2100*! 02  irr. ! 3v’.=0 . OCCOc-s 00  cpfno  1=1.0000*403  cpclad=l. 0000*403 
uclad=1.3000e406  ucool=l.C000c405 
vo!=l. 0000*400  diam=5. 0000c -02  a;t*a=l,9635e-03 
sp_2  sr=3.7806c-02 

diar0=5.0000e-02  diaml=5.G000c-02  arca0=1.9635c-03  area 1=1. 9635c -03 
ni_4  dp=8. 1537c -03 
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cxnz_l 

length=1.0000e+00  diarm5.0000e-02  area=1.9635e-03 
rat_pf=1.0000c-04  rat_m=3. 0000c -02 
nun_par=1.00 

mreq=8.7041e-01  thrust=8.9090e+03  impulse=1.0444c+03 

valv_tcv 

diant=2. 6459c -02  arca=5. 4985c -04 
mach=3 . 3662e+00  aexp=l. 5000c -02 
dp=3. 4854c 400  pf=4.0994c-02 

pi_5 

dp=8. 1537c -03 

ITK_1 

length=1.0000c400  diam=1.0000e-02  arca=7.8540e-05 
rat_pf=1.0000e-04  rat_n^8. 0000c -02 
nun_par=l  .00 

diam=2. 0000c -02  arca=3. 1416c -04 

pi_6 

dp=8. 1529c -03 

va 1 v_scv 

lcngth=1.0000c+00  diam=2.0000c-02  area=3. 1416c-04 
rat_pf=l. 0000c -04  r£t_m=l . 1000c-01 
nun  par=1.00 

dp=4.0760e+01  pf=5.0000e-01 

Pi-7 

dp=4. 0760c -03 

gt-tP 

1 eng th=l. 0000c +00  diam=2. 0000c -02  arca=3. 1416c -04 
rat_pf=1.0000e-04  rat_ro=l .  1000e-01 
nun_par=1.00 

rpn=6.0000e+04  cf£=8. 6282c -01  po*er=l  ,6907c+05 

cxnz_tp 

cmnss=l .0000c +00  cspecd=l .0000e+00 
ra  t_cmas  s=9 . 8004c -02  ra  t_c spced=l . 9467e+03 
rat_pr=1.5000c+00  incrtia=2.0000c-01 
mrcq=l .2959e-01  thrust=4.5577e+02  impulsc=3.5888c+02 

shft_l 

diam=1.2760c-02  arca=l. 2788c -04 

rpn=6. 0000c +04  powcr=3. 6989c -03  inert ia=3.0000c-01 

APPENDIX  E 


Dynamic  Example  One 


thermodynamic  data 
pc=12. 800000, 


for  HYER0GB4  wi  th  flow  id  =  THrt-  tH2 
tc=33. 200000,  tb=20. 400000,  molwt=2. 016000 


**************************  —  o  QOOOc +00  ************************************* 


output  of  model  flows 


model 

temp 

pres 

mass  enth  entr 

dens 

velc 

qual 

gas_h2 

20.0 

3.00 

0.206  -4. 1681e+06  -1.0917c+05 

7.739e+01 

1.4 

0.00 

valv_tsov 

20.0 

2.94 

0.206  -4.1681e+06  -1.0915e+05 

7.745e+01 

1.4 

0.00 

pi-1 

20.0 

2.94 

0.206  -4.1681e+06  -1.0915e+05 

7.745e+01 

1.4 

0.00 

pinp_tp 

20.0 

2.94 

0.206  -4.1681e+06  -1.0915e+O5 

7.745e+01 

1.4 

0.00 

valv_psov 

19.9 

2.88 

0.206  -4.1681e+06  -1.0914e+05 

7.750e+01 

1.4 

0.00 

pi_2 

19.9 

2.88 

0.206  -4.1681e+06  -1.0914e+05 

7.750e+01 

1.4 

0.00 

ht_r 

80.0 

2.88 

0.206  -2.8889e+06  -6.9291e+04 

8.922e-01 

29.4 

1.00 

sp_l 

80.0 

2.88 

0.191  -2.8889e+06  -6.9291e+04 

8.922e-01 

109.2 

1.00 

pi_3 

80.0 

2.88 

0.191  -2.8889e+06  -6.9291e+04 

8.922e-01 

303.4 

1.00 

reac_l 

100.0 

2.88 

0.191  -2.6266e+06  -6.6350e+O4 

7.094e-01 

137.4 

1.00 

sp_2 

100.0 

2.88 

0.176  -2.6266e+06  -6.6350e+O4 

7.094e-01 

126.6 

1.00 

cxnz_l 

24.0 

0.03 

0.176  -3.6008e+06  -6.5922e+04 

3.097e-02 

1417.4 

1.00 

sp_l 

80.0 

2.88 

0.015  -2.8889e+06  -6.9291e+04 

8.922e-01 

212.4 

1.00 

valv_tcv 

80.0 

2.88 

0.015  -2.8889e+06  -6.9283e+04 

8.905e-01 

212.4 

1.00 

pi_5 

80.0 

2.88 

0.015  -2.8889e+06  -6.9283e+04 

8.905e-01 

212.8 

1.00 

sp_2 

100.0 

2.88 

0.015  -2 . 6266e+06  -6.6350e+04 

7.094c-01 

10.7 

1.00 

pi_4 

100.0 

2.88 

0.015  -2 . 6266e+06  -6.6350e+O4 

7.093c-01 

10.7 

1.00 

ITK_1 

90.0 

2.88 

0.030  -2.7575e+06  -6.7732e+04 

7. 894c -01 

120.3 

1.00 

pi_6 

90.0 

2.88 

0.030  -2.7575e+06  -6.7732e+04 

7.894e -01 

120.3 

1.00 

valv_scv 

90.0 

2.82 

0.030  -2.7575e+06  -6.7649e+04 

7.737e -01 

120.3 

1.00 

P‘_7 

90.0 

2.82 

0.030  -2.7575e+06  -6.7649e+04 

7.737e-01 

122.7 

1.00 

gt_tp 

86.1 

1.94 

0.030  -2.8056e+O6  -6.6657e+04 

5.550c-01 

122.7 

1.00 

cxnz_tp 

70.5 

1.03 

0.030  -3.0052e+06  -6.6609e+04 

3.589e-01 

649.7 

1.00 

output  of  model  parameters 

gas_h2  diaro=5.0000e-02  area=1.9635e-03 

valv  tsov  dp=6.0000e-02  pf=2.0000e-02 

pij  dp=2.5000e-05 

lcngth=1.0000c+00  diam=5.0000e-02  area=1.9635c-03 
rat_pf=2.0000e-04  rat_m=l .0000e+00 
ntm_par=1.00 

ptnp_tp  rpn=5.0000e+03  dp=0.0000e+00  eff=6.5000e-01  po*er=0.0000e+00 

rat_dp=8.4000c+01  rat_torque=2.0577e+01  rat_rpn*6.0000c+04 
ratjn=1.0000e+00  rat_cffc=8.5000e-01  inertia=1.0000e-02 
valv_psov  dp=5. 8800c-02  pf=2.0000e-02 
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pi_2  dp=l. 2250c -05 

length=1.0000e+00  diam=5. 0000c -02  arca=1.9635c-03 

rat_pf=l. 0000c -04  rat_m=1.0000c+00 
nun_par=1.00 

hl_r  hcaI=2.6377c+05  dp  =2.4499e-04 

ua=l .0000c +05  cpwall=1.0000e403  nv^l l=0.0000e+00  vo 1=7. 853982c -03 
diam=l .0000e-01  arca=7.8540e-03  long t h=l .0000e+00 
tconst=1.0000c401 
sp _ 1  sr=7.2185e-02 

d i arO— 5 . 0000c -02  d i ami =1. 0000c -02  area0=1.9635e-03  arcal=7. 8540c -05 

pi_3  dp=l. 0544c -05 

1 eng th=l ,0000c 400  dianrf. 0000c -02  area=7.0686c-04 

rat_pf=l .0000c-04  rat_m=l ,0000c400 
num_par=l .00 

rcac_l  powr=5.0186c404  tfucl=3.0000c402  tclad=0.0000e400  dp=5.2720c-03 

lmtd=2.0984e402 

mfucl=2.0000e402  mclad=0.0000c400  cpfucl=l .0000c +03  cpclad=l .0000c403 
uclad=l .3000c406  ucoo 1=1 .0000c 404 
vo  1=1 ,0000c 400  diant=5. 0000c -02  arca=l  .9635c-03 
sp_2  sr=7.8085c-02 

diarrO=5. 0000c -02  di ami  =5. 0000c -02  areaO=l. 9635c -03  arcal=l ,9635c-03 

pi_4  dp=7. 1304c -05 

Icngth=l ,0000c 400  diam=5. 0000c -02  arca=l. 9635c -03 
rat_pf=1.0000e-04  rat_m=3. 0000c -02 
nun_par=1.00 

cxnz_l  mrcq=1.7637c-01  thrust=2.9586c402  inpulse=1.7117e402 

diant=2. 6459c -02  arca=5.4984c-04 
rrach=3 . 7422c400  acxp=l :5000c -02 
valv_tcv  dp=5.3439c-03  pf=l .8549c-03 

pi_5  dp=9. 9541c -06 

1  eng th=l. 0000c 400  diam=l. 0000c -02  arca=7. 8540c -05 
rat_pf=l .0000c-04  rat_m=8. 0000c -02 
nan_par=l  .00 

rra_l  diam=2. 0000c -02  arca=3.1416c-04 

pi_6  dp=2.1137c-05 

1 eng th=l ,0000c 400  diam=2. 0000c -02  arca=3.1416c-04 
rat_pf=1.0000e-04  rat_m=l .  1000c-01 
nun_par=l  .00 

valv_scv  dp=5.7511c-02  pf=2.0000e-02 

pi_7  dp=2.0714c-05 

lcngth=l .0000c400  diam=2. 0000c -02  area=3. 1416c-04 
rat_pf=l ,0000c -04  rat_m=l .  1000c -01 
nim_par=l  .00 

gt_tp  rpm=5.0000c403  cf£=3. 6967c -01  pcwr=1.4364c403 

cmass=l  .0244e400  cspeed=2. 7074c -01 
rat_cmass=9. 8004c -02  rat_cspccd=l .9467C403 
rat_pr=l .5000c 400  inert ia=2.0000c-02 
cxn/,_tp  mrcq=2.9826c-02  thrust=3.2667e401  inpulsc=l.  1177C402 

dian*=l. 2760c -02  arca=l .2788c-04 

shft_l  rpm=5.0000c403  powcr=l .4364C403  inert ia=3.0000e-02 

cntl_l  ent 1=2. 0000c -02  crr=-2. 7500c 400  icrr=0.0000c400  dcrr=0.0000c400 

k=1.0000c400  tp=1.0000c400  ti=0.0000c400  td=1.0000c400 


****+****4.*******+********  (jffg  =  1.0000c401  ************************************* 
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output  of  model  flows 


model 

tenp 

pres 

mass  enth  entr 

dens 

vclc 

qual 

gas_h2 

20.0 

3.00 

0.273  -4. 1681e+06  -1.0917e-K)5 

'T.739e+01 

1,8 

o.eo 

valv_tsov 

20.0 

2.94 

0.273  -4.1681e+06  -1.0915e+05 

7.745e+01 

1.8 

0.00 

Pi_l 

20.0 

2.94 

0.273  -4.1681e+06  -1.0915e-t05 

7.745e+01 

1.8 

0.00 

pump_tp 

23.4 

8.15 

0.273  -4. 1576e+06  -1.0812e+05 

7.151eH01 

1.8 

0.00 

valv_psov 

23.3 

7.98 

0.273  -4.1576e+06  -1.0813e+05 

7.162e-t01 

1.8 

0.00 

pi  2 

23.3 

7.98 

0.273  -4.1576e-+06  -1 ,0813e+05 

7.162e+01 

1.9 

0.00 

ht_r 

59.3 

7.98 

0.273  -3.1908e+06  -7.7807e404 

3.493e+00 

9.9 

1.00 

sp_l 

59.3 

7.98 

0.268  -3.1908e+06  -7.7807e+04 

3.493C+00 

39.1 

1.00 

PL3 

59.3 

7.98 

0.268  -3.1908e+06  -7.7807e+04 

3.493e+00 

108.6 

1.00 

reac_l 

428.5 

7.95 

0.268  1.7699e+06  -5.1176e-+04 

4.548e-01 

300.3 

1.00 

sp_2 

428.5 

7.95 

0.233  1  "7699e+06  -5.1176c404 

4.548c -01 

261.3 

1.00 

cxnz_l 

110.2 

0.09 

0.23.',  2  4861e+06  -5.0583C4O4 

1.933e-02  2971.1 

1.00 

sp_l 

59.3 

7.98 

0.005  -•>  1908e+06  -7.7807c+04 

3.493C+00 

17.0 

1.00 

valv_tcv 

59.3 

7.95 

0.005  1908e+06  -7.7792C404 

3.480e+00 

17.0 

1.00 

pi_5 

59.3 

7.95 

0.005  -3.1908e+06  -7.7792e+04 

3.480e+00 

17.1 

1.00 

sp_2 

428.5 

7.95 

0.035  1.7699e-f06  -  5.1176e-K)4 

4.548e-01 

39.0 

1.00 

pi_4 

428.5 

7.95 

0.035  1.7699e+06  -5.1176e404 

4.548e-01 

39.0 

1.00 

mt_l 

385.7 

7.95 

0.039  1 . 1833e+06  -5.2619e404 

5.053C-01 

248.5 

1.00 

pi_6 

385.7 

7.95 

0.039  1 . 1833e+06  -5.2619e404 

5.053e-01 

248.5 

1.00 

valv_scv 

385.7 

7.79 

0.039  1.1833C406  -5.2535e404 

4.952e-01 

248.5 

1.00 

Pi-7 

385.7 

7.79 

0.039  1.1833C406  -5.2535e-t04 

4.952e -01 

253.6 

1.00 

gt_tp 

368.2 

5.34 

0.039  9.4542e-t05  -5.1605e404 

3.557e -01 

253.6 

1.00 

cxnz_tp 

304.3 

2.85 

0.039  8.1564e+04  -5.1587c404 

2.298e -01 

1343.4 

1.00 

output  of  model  parameters 

gas_h2  diam=5.0000e-02  arca=1.9635e-03 

valv_tsov  dp=6. 0000c -02  pf=2. 0000c -02 

pi_l  dp=4.3764e-05 

pimp_tp  rpm=1.5073c404  dp=5.2063c+00  eff=6.5000c-01  pcwcr=-2.8588e403 

valv_psov  dp=1.6293e-01  pf=2.0000e-02 

pi_2  dp=S.9419e-05 

ht_r  hcat=2.6377e+05  dp  =1.1 884c -03 

sp_l  sr=1.7098c-02 

pi_3  dp=5. 7396c -05 

rcac  1  pavcr=2.8345c+07  tfucl=9.5966c+02  tclad=£.0000c+00  dp=2.8698e-02 

lmtd=£.9961e+02 
sp_2  sr=1.2972e-01 

pi_4  dp=7.9533e-04 

exnz_l  mreq=2. 3337c -01  thrust=8.2509e+02  impul se=3.6077e-K)2 

valv_tcv  dp=2.9548e-02  pf=3.7017c-03 

pi_5  dp=2. 7039c -06 

p i _6  dp=l . 0228e - 04 

valv_scv  dp=1.5905e-01  pf=2.0000e-02 

p  i _ 7  dp— 1 ,0024e-04 

gt_tp  rpn=1.5073e+04  ef£=4.18l9e-01  power=9.3860c-t03 

arass=l .0143C400  cspced=3 .9427e-01 
cxnz_tp  mreq=3.9449e-02  thrust=8.9914e+01  inpul  se=2.3258e+02 

shf t_l  rpm=l  .5073c+04  pcwer=6.5272c+03  inert ia=3.0000c-02 

ent I_1  cntl=2.0000e-02  err=-2.2464c+00  icrr=0.0000e400  derr=0.0000c+00 
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**************************  tin£  —  2  O000e+0l  ************************************* 


output  of  model  flosvs 


model 

tenp 

pres 

mass  enth  entr 

dens 

vclc 

qual 

gas_h2 

20.0 

3.00 

0.712  -4. 1681e+06  -1.0917e+05 

7.739e+01 

4.7 

0.00 

valv_tsov 

20.0 

2.94 

0.712  -4.1681e+06  -1.0915e405 

7.745e-K)l 

4.7 

0.00 

pi_l 

20.0 

2.94 

0.712  -4. 1681c+06  -1.0915e405 

7.745c+01 

4.7 

0.00 

purp_tp 

27.7 

30.07 

0.712  -4.1135e+06  -1.0629e+05 

6.797C+01 

4.7 

1.00 

valv_psov 

27.7 

29.47 

0.712  -4.1135C-+06  -1.0626e-K)5 

6.784e+01 

4.7 

1.00 

pi  2 

27.7 

29.47 

0.712  -4. 1135e+06  -1.0626e-K)5 

6.784e+01 

5.3 

1.00 

ht_r 

41.1 

29.44 

0.712  -3.7431C+06  -9.4009e+04 

3.474e+01 

2.6 

1.00 

sp_l 

41.1 

29.44 

0.701  -3.7431e+06  -9.4009e+04 

3.474c+01 

10.3 

1.00 

pi_3 

41.1 

29.44 

0.701  -3.7431C+06  -9.4009e404 

3.474c+01 

28.6 

1.00 

reac_l 

803.7 

28.71 

0.701  7.0864e+06  -4.7608e-+04 

8.721e-01 

409.4 

1.00 

sp_2 

803.7 

28.71 

0.609  7.0864c+O6  -4.7608e4O4 

8.721c-01 

355.7 

1.00 

cxnz_l 

225.7 

0.33 

0.609  -9.6784e+05  -4.6659e4C4 

3.573c-02 

4125.4 

1.00 

sp_l 

41.1 

29.44 

0.011  -3.7431e+06  -9.4009e+04 

3.474e+01 

4.1 

1.00 

valv_tcv 

40.9 

28.71 

0.011  -3.7431e+06  -9.3968e+04 

3.433e+01 

4.1 

1.00 

pi_5 

40.9 

28.71 

0.011  -3.7431C+06  -9.3968e+04 

3.433c+01 

4.1 

1.00 

sp_2 

803.7 

28.71 

0.092  7.0864c+06  -4.7608c+O4 

8.721C-01 

53.7 

1.00 

pi_4 

803.7 

28.71 

0.092  7.0864c+06  -4.7608e-t04 

8.720c-01 

53.7 

1.00 

rm_l 

723.3 

28.71 

0.103  5.9223C+06  -4.9134e404 

9.684e-01 

338.8 

1.00 

pi_6 

723.3 

28.71 

0.103  5.9223c+06  -4.9134e404 

9.6S4c-01 

338.8 

1.00 

valv  sev 

723.3 

28.13 

0.103  5.9223C+06  -4.905Cc-t04 

9.491C-01 

338.8 

1.0C 

Pi-7 

723.3 

28.13 

0.103  5.9223c+06  -4.9049e+04 

9.490C-01 

345.7 

1.0C 

gt_tp 

673.7 

19.05 

0.103  5.2070C+06  -4.8457c+04 

6.913c-01 

345.7 

1.0C 

cxnz_tp 

563.1 

10.26 

0.103  3.6394e-f06  -4.8435e+04 

4.461c-01 

1812.3 

1.0C 

output  of  model  parameters 


gas_h2 

diam=5.0000e-02  arca=1.9635e-03 

valv_tsov 

dp=6.0000e-02  pf=2.0000e-02 

Pij 

dp=2.9826e-04 

purp_tp 

rpn=3.5812e+04  dp=2.7130e+0l  cff=6.5000e-01  poAcr=-3.8891e-K)4 

valv_psov 

dp=6.0140c-01  pf=2.0000c-02 

pi  2 

dp=l .4948c -03 

ht_r 

heat=2.6377e+05  dp  =2.9894e-02 

sp_l 

sr=1.5556e-02 

P>_3 

dp=l  .4471c-03 

rcac_l 

powr=4.2109e+07  tfuel=2.5196c+03  tclad=0.0000e-KX)  dp=7.2350c-01 
lmtd=2.0739c+03 

sp_2 

sr=1.3120e-01 

pi_4 

dp=2.8712e-03 

cxnz_l 

mrcq=6.0903e-01  thrust=3.0118c+03  impulse=5.0452e+02 

valv_tcv 

dp=7.2764c-01  pf=2.4718e-02 

pi_5 

dp=5.5062e-05 

pi_6 

dp=2. 5203c -03 

valv_scv 

dp=5.7414c-01  pf=2.0000e-02 

P'-7 

dp=2.4697e-03 

gt-tP 

rpna=3.5812e+04  cff=6.4662c-01  power=7.3725e+04 
cmass=l .0054c+00  cspeed^6.8401e-01 

cxnz_tp 

mrcq=l ,0319c-01  thrust=3.1967e+02  impul sc=3.1649c+02 

shft_l 

rpm=3.5812e+04  powcr=3.4834c+04  inert ia=3.0000e-02 
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cnt 1_1  cntl=2.0000e-02  err=-1.2094e+00  icrr=0.0000e+00  derr=0.0000c+00 


******************+*******  ^  imc  =  3  0000c+01  ************************************* 


output  of  model  flows 


model 

temp 

pres 

mass  enth  entr 

dens 

velc 

qual 

gas_h2 

20.0 

3.00 

1.211  -4. 1681e+06  -1.0917e+05 

7.739e+01 

8.0 

0.00 

valv_tsov 

20.0 

2.94 

1.211  -4. 1681e+06  -1.0915e+05 

7.745e+01 

8.0 

0.00 

pi-1 

20.0 

2.94 

1.211  -4. 1681e+06  -l.O915e+05 

7.745e+01 

8.0 

0.00 

punp_tp 

31.3 

65.56 

1.211  -4.0421e+06  -1.0493e+05 

6.969e+01 

8.0 

1.00 

valv_psov 

31.3 

64.25 

1.211  -4.0421e+06  -1.0487e+05 

6.941e+01 

8.0 

1.00 

pi_2 

31.3 

64.24 

1.21-1  -4.0421e+06  -1.0487e405 

6.941e+01 

8.9 

1.00 

ht_r 

42.3 

64.05 

1.21-1  -3.8242e+06  -9.7708e+04 

5.372e+01 

2.9 

1.00 

sp_l 

42.3 

64.05 

1.191  -3.8242e+06  -9.7708e+O4 

5.372e+01 

11.3 

1.00 

pi_3 

42.3 

64.05 

1.191  -3.8242e+06  -9.7707e+04 

5.372e+01 

31.4 

1.00 

reac_l 

1118.0 

60.84 

1.191  1 . 1791e+07  -4.5795c+04 

1 . 323e+00 

458.2 

1.00 

sp_2 

1118.0 

60.84 

1.086  1.1791e+07  -4.5795e+04 

1 .323e+00 

417.9 

1.00 

exnz_l 

334.1 

0.72 

1.086  4.8451C405  -4.4643e+04 

5. 287c -02 

4917.5 

1.00 

sp_l 

42.3 

64.05 

0.020  -3.8242e+06  -9.7708e+04 

5.372c+01 

4.8 

1.00 

valv_tcv 

42.1 

60.84 

0.020  -3.8242C406  -9.7583e+04 

5.289c+01 

4.8 

1.00 

pi_5 

42.1 

60.84 

0.020  -3.8242e406  -9.7583e+04 

5.289e401 

4.9 

1.00 

sp_2 

1118.0 

60.84 

0.105  1 . 1791e+07  -4.5795C404 

1.323c+00 

40.3 

1.00 

pi_4 

1118.0 

60.84 

0.105  1 . 1791e+07  -4.5795e+04 

1 . 323e+00 

40.3 

1.00 

mx_l 

949.2 

60.84 

0.125  9.2469e+06  -4.8262e+04 

1.556C400 

256.2 

1.00 

pi_6 

949.2 

60.83 

0.125  9.2469e+06  -4.8262e+04 

1 . 556c+00 

256.2 

1.00 

valv_scv 

950.0 

39.38 

0.125  9.2469e+06  -4.6451e+04 

l.Ollc+OO 

256.2 

1.00 

Pi_7 

950.0 

39.38 

0.125  9.2469c+06  -4.6451e+04 

1 .011e+00 

394.4 

1.00 

gt-tp 

866.2 

26.32 

0.125  8.0004e+06  -4.6151e-t04 

7.423e-01 

394.4 

1.00 

cxnz_tp 

728.9 

14.25 

0.125  5.9974e+06  -4.6126e404 

4. 785c -01 

2050.7 

1.00 

output  of  model  parameters 


gas_h2 

diam=5.0000e-02  arca=1.9635e-03 

valvjsov 

dp=6.0000e-02  pf=2.0000c-02 

Pi_l 

dp^5 . 8800e -04 

punnp_tp 

rpm=5. 7052c t04  dp=6.2619c+01  cff=6.5000e-01  powcr=- 1.5262c +05 

valv_psov 

dp=1.3112e+00  pf=2.0000c-02 

pi  _2 

dp=6.4247e-03 

ht_r 

heat=2.6377e+05  dp  =1.8840e-01 

sp_l 

sr=1.6848e-02 

pi_3 

dp=6.4052e-03 

reac_l 

pcwcr=4.2109e+07  tfuel=3.3436e+03  tclad=0.0000c+00  dp=3.2023c+00 
lmtd=2.7282e+03 

sp_2 

sr=8.8040e-02 

pi_4 

dp=6.0843e-03 

exnz_l 

mrcq=1.0857e+00  thrust=6.4321e+03  impulse=6.0452e+02 

valv_tcv 

dp=3.2144c+00  pf=5.0184c-02 

pi_5 

dp=3.9568e-04 

pi_6 

dp=6.0837e-03 

valv_scv 

dp=2. 1448c+01  pf=3.5258e-01 

P>  J 

dp=3. 9383c -03 

gt_tp 

rpm=5.7052e+O4  cff=8.2917c-01  powcr=l  ,5608e+05 

88888888888888888888888 
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cxnz_tp 
shft_l 
cnt 1_1 


cmass=l .OOOOc+OO  cspced=9.5084e-01 
mrcq=1.2522e-01  thrust=4.4137e+02  impulse=3.5968c402 
rpm=5.7052c+04  powcr=3.4589c+03  inert ia=3. OOOOc -02 
cntl=3.5258e-01  err=-l  .4742c-01  icrr=0. OOOOc+OO  dcrr=0. OOOOc+OO 


APPENDIX  F 


Thermionic  System  Exam^e 


task:  a  n=0  f=2.244738c+04 
x=  8.000000c+05 
c=  2.244738c+04 

h=  2.3043c+ll  hs=  2.3043c+ll  mt=0.00e+00  n=2.30c+ll  s=2.30c+ll  a=1.00c+00  b=0  b=0 

task:  a  n=l  f=8.971750e+03 
x=  5.599855e+05 
c=  8.971750e+03 

h=  3.6809e+10  hs=  3.68d7c+10  nu=2.00e+00  n=2.55c+10  s=2.55e+10  a-l.OOe+OO 

task:  a  n=2  f=5 . 562803e+02 
x=  4.401386C405 
c=  5 . 562803e+02 

h=  1.4151c+08  hs=  1.4151C408  mu=1.00c+00  n=6.28e+07  s=6.28e+07  a=1.00c+00 

task:  a  n=3  f=3. 96043 lc-tOl 
x=  4.322164c+05 
c=-3.960431c+01 

h=  7 ! 1 728c+05  hs=  7.1728c+05  mj=0.00c+00  n=2.77e+05  s=2.77c+05  a=1.00c+00 

task:  a  n=4  f=1.523882c-01 
x=  4.327430c+05 
c=  1.523882c -01 

li=  1.0620c+01  hs=  1.0620e+01  mu=0.00c+00  n=4.07c+00  s=4.07c+00  a=  1.00c +00 

task:  a  n=5  f=4. 142651c -05 
x=  4.327409c+05 
c=  4.142651C-05 

output  of  model  flows 


model 

power  vol tage 

current 

watts  volts 

anps/s 

rcac_l 

5.626e+04  0.000 

O.OOOe+OO 

ti_l 

5.626c+04  6.000 

9 . 376e+03 

sp_shunt 

5.569e+04  6.000 

9.282e+03 

rcs_ti 

4.708e+O4  5.072 

9.282e+03 

bc_l 

4.002e+04  100.000 

4.002e+02 

rcs_bc 

4.000e+04  99.960 

4.002e+02 

bus_l 

4.000C+04  99.960 

4.002e+02 

rcac_l . s 

3.765c+05  0.000 

0i000e+00 

rad_prim 

3.765C+05  0.000 

O.OOOe+OO 

sp_shunt.s 

5.626e+02  6.000 

9.376e+01 

rad_shunt 

5.626e+02  0.000 

0:000e+00 

bc_l . s 

7.062e+O3  0.000 

O.OOOe+OO 

rad_bc 

7.062c+O3  0.000 

O.OOOe+OO 
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rcac_l 

ti_l 

sp_shunt 

bc_l 

rcs_ti 

rcs_bc 

rad_prim 

rad_shunt 

rad_bc 

l)US_l 


model 

rcac_l 
rcac_l.ss 
rcac_l .rs 
rcac_l .bocm 
tij 

rad_prim 

rad_shunt 

rad_bc 

mass_sys.dist 

noss_sys.ic 

mass_sys 


output  of  model  parameters 

paM32740,9382  cf£=0.1300  radius=0.20  hcight=158.29 
radiusrs=88.670  volrs=0.000  hcightrs=O.370  scp=10.000 
v=6.0000  vconv=0.67  iconv=62.00  ncs=3.96  ncp=151.23 
sr=0.0100 

cf 1=0.8500  v=100.0000 

r=0.0001 

r=0.0001 

arca=78.4625  t =1000. 00  tspace=255.00  e=0.85  rho=44.00  mass=3452.35 
arca=5.4627  t=400.00  tspace=255.00  c=0.85  ho=44.00  mass=240.36 
area=68.5710  t=400.00  tspacc=255.00  c=0.85  rho=44.00  mass=3017. 13 
pow:r=4.000c404  vol tagc=9.996c+01  currcnt=4.0()2e+O2 

output  of  model  masses 

mass 

kg 

1.385C403 

l.OOOc+02 

1.466e-t03 

9.000c+01 

7.363C402 

3.452c+03 

2.404C4O2 

3.017C403 

2.200e+02 

2.220c-fO2 

1.093C4O4 


APPENDIX  G 


Performance  Map  Layout® 


Several  of  the  dynamic  models  make  use  of  performance  maps  which  are  read  from  a  file.  Each  of  these  perfor¬ 
mance  maps  consists  of  functions  of  cither  one  or  two  independent  variables.  This  section  describes  the  layout 
within  the  files  of  this  data  and  the  interpolation  classes  that  are  used  to  obtain  the  data  and  to  perform  the  inter¬ 
polations.  These  interpolations,  at  present,  arc  only  multilinear. 

We  start  with  the  one  dimensional  interpolations.  This  class  is  used  to  define  z  as  a  function  of  x  given 
Xj  ,z,-  pairs,  where  i=0  to  n ,  as  follows. 

t=min(max(x^0)^) 


z=zi+(t-xi)  (zi+1-z,)/(x,+1-jr,) 

where  i  is  the  largest  /  such  that  x>x-,,  i<n.  The  class  structure  is  defined  as 

struct  intpl 
(char  labcl[16]; 
double  *x,  *z,  y; 
int  n,  im; 

}; 

void  intpl  ncwO; 
void  intpl inO; 
double  intplcO; 

The  variables  have  the  following  meaning, 
label  -  user  defined  name  for  the  data, 

x  -  pointer  to  the  array  of  grid  values, 

z  -  pointer  to  the  array  of  z,-  grid  values. 

y  -  additional  value  for  this  data;  used  only  for  two-dimensional  interpolations, 

n  -  number  of  elements  in  the  x  (and  ?)  arrays. 

im  -  additional  parameter  used  only  in  emally  in  the  two-dimensional  interpolations. 

One  member  function  in  is  defined  for  the  class,  which  is  called  with  a  pointer  argument  to  the  data  struc¬ 
ture  and  with  a  file  descriptor  argument  to  read:the  data.  The  data  in  this  file  is  in  the  following  order  separated 
by  blanks  or  new  lines.  First,  the  user  dcfinedilabel  is  specified,  followed  by  the  number  n  of  elements  in  the  x 

array  and  then  followed  by  the  additional  y  value.  If  only  a  one  dimensional  interpolation  is  being  done,  this  y 

value  may  simply  be  set  to  zero.  Following  these  three  items,  are  the  n  sets  of  x,z  pairs. 

The  function  intplc  for  the  class  defines  the  function  for  doing  the  interpolation.  This  function  takes  as 
arguments  a  pointer  to  the  data  structure  and  a  double  precision  variable  representing  the  independent  variable 
value.  As  an  example  of  its  use,  suppose  the  file  INI  contains  the  data  (laid  out  as  specified  above)  for  the  pump 
head  as  aTunetion  of  pump  rpm.  In  this  case  the  rpm  values  would  be  the  x  array  and  the  head  values  the  z 
array.  The  coding  necessary  to  read  in  the  data  and  then  interpolate  to  find  the  head  for  some  rpm,  would  be  as 
follows. 

#inciude  "util.h" 
mainO 

(double  h,  rpm=600; 


99 


100 


FILE  *inp; 
struct  intpl  head; 
inp=fopcn("INr,"r"); 
intpl  in(&hcad,inp); 
h=intp  1  c(&hcad  ,rpm) ; 

) 

Note,  the  interpolations  classes  arc  defined  within  the  "util.h"  header  file.  Here  a  file  descriptor,  inp  is  declared 
and  associated  with  the  file  named  "INI"  using  the  fopen  function,  then  the  head  variable  is  declared  as  a  intpl 
class  instance,  the  intplin  function  is  called  with  the  file  descriptor  as  an  argument  to  read  in  the  head  data, 
then  intplc  is  called  to  return  the  value  of  the  head  for  some  rpm  value,  in  this  ease,  600  rpm. 

The  reason  the  file  descriptor  is  used  within  the  intplin  function  rather  than  the  file  name  is  so  a  single 
file  can  be  opened  and  used  with  several  interpolation  classes.  This  is  done  in  the  pump  model  where  both  the 
head  and  the  torque  curves  are  defined  as  intpl  classes  with  both  sets  of  data  in  the  same  file.  The  independent 
argument,  however,  is  not  the  rpm  as  in  this  simple  example.  More  on  that  Liter. 

The  two  dimensional  interpolations,  z  as  a  function  of  x  and  y ,  are  performed  by  interpolating  ov<_r  two 
fixed  y  grid  values  as  one  dimensional  interpolations  over  x  and  then  interpolating  these  results  as  a  one  dimen¬ 
sional  interpolation  over  y.  As  an  option  a  curve  in  the  x,y  plane  can  be  input  that  describes  some  prominent 
feature  of  the  surface  i ,  say  a  ridge  or  valley,  and  the  x  interpolations  arc  then  performed  relative  to  this  feature 
curve.  That  is,  if  the  feature  curve  is  denoted.  x~Xftat(y),  then  the  x  interpolations  at  the  two  y  grid  values  arc 
made  at  x;tal  (ygnd )+x (y ),  where  ytnd  is  the  y  grid  values.  These  two  interpolation  values  arc  then  inter¬ 
polated  as  a  one  dimensional  interpolation  over  y  as  before. 

The  two  dimensional  interpolation  class  structure  is  defined  as  follows. 

struct  intp2 
(int  n,  ifeat; 
intpl  *a; 

); 

void  intp2in(); 
double  intp2c(); 

The  variables  have  the  following  meaning, 
n  -  number  of  y  grid  values. 

ifeat  -  flag  indicating  that  the  interpolations  arc  to  be  performed  along  some  feature 

on  a  rectangular  x,y  grid. 

a  -  po:nter  to  an  array  of  one  dimensional  interpolation  classes  used  to  hold  all 

each  of  these  classes  the  y  variable  holds  the  fixed  y  grid  value. 

The  use  of  this  two  dimensional  interpolation  class  is  exactly  like  the  one  dimensional 
the  class  is  called  as  a  function  of  two  variables.  The  intp2in  function  makes  use  of  the  inptlin  function  to 
obtain  the  data.  The  complete  layout  of  the  inpt2  data  consists  of  eight  dr  ..y  numbers  (these  numbers  were 
originially  used  to  define  a  graphical  rcrcscntation  of  the  data  but  are  currently  not  used)  followed  by  the 
number,  n,  of  y  grid  values.  These  arc  then  followed  by  n  sets  of  one  dimensional  interpolation  data  laid  out 
exactly  as  with  the  inf  pi  class  data.  The  last  of  these  intpl  sets  may  have  the  label,  "feature",  indicating  that 
this  set  represents  the  feature  curve.  In  this  case  the  x  values  of  the  data  represent  the  y  values  of  the  feature 
curve,  and  the  z  values  represent  the  x  values  of  the  feature  curve.  Other  than  the  use  of  the  "feature"  label,  the 
label  used  on  the  intpl  data  sets  really  isn’t  used  for  the  intp2  class,  although,  some  dummy  label  needs  to  be 
supplied. 

With  these  interpolation  classes  defined,  we  can  now  consider  the  actual  performance  maps  that  arc  used 
by  die  dynamic  pump,  compressor,  and  gas  turbine  models. 

The  pump  model  requires  two  maps,  one  for  a  nondirnensional  head  and  one  for  a  nondimcnsional  torque, 
where  a  nondimcnsional  quantity  is  defined  by  division  by  its  rated  value.  These  nondimcnsional  head  and 
torque  curves  arc  defined  by 


curve  rather  than 
of  die  data.  For 
class  except  dial 
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lln=(m?+rpm?)  H (x) 
Tn=(m?+rpm?)  T(x) 

where 


-1/  ^  X 

x=7t+tan  ‘( - ) 

rpm* 

and  the  functions,  H(x)  and  T(x),  are  the  normalized  head  and  torque  curves  at  m?+rpm£=  1.  The  pump  perfor¬ 
mance  map  file  contains  H(x)  as  the  first  intpl  class  data  and  T(x)  as  the  second  intpl  class  data. 

The  compressor  model  also  has  two  performance  maps,  one  for  the  pressure  ratio  and  one  for  the 
efficiency.  This  time  the  maps  are  functions  of  two  parameters,  the  corrected  mass  and  corrected  rpm,  defined 
as 


mVT 


Pr 


rpmcor= 


rpml'ft 

rpmrlJTr 


where  the  r  subscript  refers  to  rated  conditions.  The  corrected  mass  parameter  is  treated  as  the  x  variable  and 
the  corrected  rpm  as  the  y  parameter  in  a  two  dimensional  interpolation.  Both  of  these  performance  maps  arc 
stored  within  the  same  file  with  the  pressure  ratio  map  specified  first 

The  gas  turbine  model  has  exactly  the  same  set  of  performance  maps  (although  the  maps  themselves  arc 
different)  as  the  compressor  model.  Note,  that  for  both  the  compressor  and  the  gas  turbine,  the  model  will  per¬ 
form  some  additional  scaling  of  the  resulting  pressure  ratio  and  efficiency  as  explained  .within  the  section 
describing  the  models. 


